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ABSTRACT 


This  report  documents  a simulation  model  (DELCAP)  designed 
to  estimate  airport  throughputs  and  aircraft  delays,  taking  into 
account  their  dependence  on  (1)  the  traffic  level  and  mix  of  user 
types,  (2)  the  airport  configuration,  and  (3)  the  separation 
rules  in  force.  The  model  is  implemented  in  two  parts:  a preprocessor 

to  facilitate  data  entry  by  providing  standard  data  input  which  a user 
may  elect  instead  of  providing  his  own,  and  an  event -oriented  simulation 
model.  The  report  includes  a discussion  of  the  elements  in  the  airport 
system  which  are  modeled,  a description  of  the  simulation  model's  logic, 
and  a set  of  sample  outputs.  Listings  of  the  model  programs,  and  a 
users'  guide  to  their  operation,  appear  as  appendices.  The  report 
concludes  with  suggestions  for  next  steps  in  this  development  effort, 
including  validity  and  sensitivity  analyses,  model  modification,  and 
data  collection. 


1.  INTRODUCTION 


DELCAP  is  a fast -time  computer  simulation  model  designed  to 
provide  measures  of  airport  throughput  and  user  delays  (under  IFR 
operations) , for  a broad  range  of  scenarios  described  by 

(a)  airport  configurations  and  operating  modes 

(b)  mixes  of  user  aircraft  types,  and 

(c)  separation  criteria. 

It  is  presently  conceived  as  mainly  a planning  and  analysis  tool, 
for  use  in  answering  single  queries  or  a series  of  "what  if?"  questions 
concerning  what  effects  changes  in  (a)  and/or  (b)  and/or  (c) 
would  have  on  delays  and  throughputs. 

The  model  is  written  in  the  "simulation  language"  SIMSCRIPT  1.5, 
and  is  presently  operational  on  the  UNIVAC  1108  computer  at  the 
National  Bureau  of  Standards  (NBS) . In  addition  to  the  simulation, 
there  is  a FORTRAN  preprocessing  program  which  allows  the  user  to 
provide  model  input  in  an  easier  and  more  flexible  manner  than  that 
required  by  the  standard  SIMSCRIPT  input  format. 

The  model  has  been  run  for  a variety  of  airport  runway 
configurations  and  is  believed  to  be  capable  of  handling  all  the 
configurations  schematized  in  Table  1 of  FAA’s  AC  150/5060-3A 
("Airport  Capacity  Criteria  Used  in  Long  Range  Planning"),  under 
any  mode  of  operation  which  has  been  described  to  us  as  "reasonable". 
(An  example  of  an  "unreasonable"  mode  of  operation  is  an  open  V 
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configuration  operating  away  from  the  point  and  having  landings 
on  both  runways.  In  this  case  the  landing  patterns  would  cross 
in  the  air.) 

The  design  of  a computer  simulation  model  is  generally 
guided  (either  explicitly  or  implicitly)  by  one  of  two  opposing 
philosophies.  The  first  of  these,  which  might  be  termed  the 
"include  every  detail"  view,  aims  at  maximum  realism;  its  ideal 
is  a model  which  closely  and  comprehensively  mirrors  all  the  workings 
of  the  process  being  simulated.  It  is  hoped  that  such  a model 
will  "leave  nothing  out"  and  will  thus  be  capable  of  answering 
almost  any  reasonable  question  which  might  be  asked  about  the  system 
under  study.  One  consequence  is  that  modeling  and  programming  efforts 
can  proceed  without  awaiting  prior  specification  in  operational 
terms  of  just  what  questions  are  to  be  posed. 

On  the  negative  side,  however,  such  models  are  necessarily 
expensive  to  build,  to  provide  with  reliable  data  at  the  required 
level  of  detail,  and  to  run.  They  are  usually  so  large  and  compli- 
cated that  only  experienced  computer  personnel  can  operate  them. 
Because  of  these  drawbacks,  a common  result  is  that  they  are  run 
only  a few  times  (if  at  all) . Moreover  their  development  involves 
a special  danger:  building  the  "perfect  model"  tends  to  become  an 

end  in  itself,  the  designer  losing  sight  of  why  it  was  desired  in 
the  first  place. 
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The  other  view,  which  might  be  called  the  "model  as  little 


as  you  can"  philosophy,  holds  that  models  should  be  designed  to 
answer  specific  classes  of  questions,  and  should  include  only 
those  details  of  the  system  being  modeled  which  directly  affect  the 
answers  to  these  questions.  Such  models,  therefore,  usually 
cannot  adequately  answer  questions  other  than  those  for  which 
they  were  designed.  There  is  also  the  danger,  in  designing  such 
a model,  of  omitting  some  relevant  detail  because  its  relevance 
was  not  recognized  in  time.  This  risk  can  never  be  eliminated 
absolutely,  but  it  can  be  reduced  to  a level  acceptable  in  practice 
by  careful  study  of  the  system  before  actual  design  of  the  simulation 
is  begun.  Indeed,  proponents  of  the "model  as  little  as  you  can" 
view  usually  spend  at  least  as  much  time  in  studying  the  system 
as  in  the  construction  of  the  simulation  model  itself. 

The  advantage  of  this  particular  approach  is  that  the  model 
is  of  manageable  size,  and  therefore  easier  and  less  expensive  to 
operate.  It  can  actually  be  used  by  planners,  to  answer  questions 
of  the  type  it  was  designed  to  answer.  Because  of  this  ease 
and  low  cost  of  operation,  many  different  cases  and  variations 
can  be  simulated. 

There  is  a drawback  to  the  "model  as  little  as  you 
can"  approach,  which  may  well  be  the  real  reason  many  modelers 
subscribe  to  the  "include  every  detail"  philosophy.  A model  which 
is  more  "abstract",  i.e.  which  is  based  on  deliberate  and  selective 
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abstracting  from  real-world  complexity , is  also  more  difficult 
to  explain.  Use  of  such  a model  lays  the  designer  open  to 
accusation  of  ”why  did  you  omit  this  or  that  detail?”,  and  leaves 
him  with  a genuinely  difficult  task  if  the  model  must  be  explained 
solely  in  the  operationally- oriented  terms  familiar  to  the  potential 
user  of  the  simulation.  A proper  description  should,  however, 
produce  conviction  that  the  model  includes  all  those  aspects 
of  the  system  essential  for  answering  the  questions  at  which  it  is 
directed. 

In  this  project,  we  have  subscribed  to  the  second,  ’’model  as 
little  as  you  can”,  point  of  view.  The  present  document  is  there- 
fore designed  to  describe,  to  the  prospective  user  of  the  DELCAP 
simulation,  which  elements  of  the  air  transportation  system  have 
been  modeled  and  how  they  are  represented.  Chapter  2 will  provide 
a description  of  the  terminal  area  as  seen  through  the  eyes  of  the 
model.  Chapter  3 will  provide  a more  computer-oriented  view  of 
the  model.  The  input  data  which  are  needed  will  also  be  discussed 
in  this  chapter.  Model  outputs  are  taken  up  in  Chapter  4,  which 
includes  descriptions  of  a number  of  sample  ’’runs”  of  the  model. 
Chapter  5 summarizes  the  present  form  of  the  DELCAP  effort,  and  lists 
some  possible  directions  for  future  work  to  make  DELCAP  an  even 
useful  tool.  This  chapter  also  describes  how  the  model  might  operate 
in  a computer  time -sharing  environment  as  a highly  accessible 
analysis  tool  A bibliography  is  included  as  Chapter  6. 
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There  are  eight  appendices  to  this  report.  The  first  of  these, 
.Appendix  A,  gives  input  formats  and  operating  instructions  for  any 
user  who  wishes  to  run  the  model.  Sample  input  decks  are  also  portrayed. 
This  section  is  intended  for  readers  without  extensive  computer  backgrounds 
but  those  with  more  computer  experience  should  also  find  it  useful. 

It  can  best  be  described  as  a "DELCAP  users'  manual'’,  which  includes 
information  necessary  for  running  the  existing  code. 

The  next  four  appendices  are  meant  for  the  programming-oriented 
reader  who  might  be  interested  in  altering  the  code  or  in  transferring 
it  to  a different  computer.  Appendix  B gives  a list  of  the  model 
elements,  subroutines,  variables  and  arrays  used  both  in  the  DELCAP 
simulation  and  its  preprocessor.  Appendices  C and  D give  listings 
of  the  preprocessor  and  the  simulation,  respectively. 

The  preprocessor  is  written  in  FORTRAN  and  the  simulation  is 
SIMSCRIPT.  Both  of  these  languages  are  available  on  a wide  range 
of  computers . However,  as  anyone  who  has  worked  on  several  different 
computers  is  well  aware,  the  implementation  of  the  same  language 
on  different  "machines”  is  apt  to  be  quite  different.  Appendix  E 
has  been  prepared  to  document  those  properties  of  the  DELCAP  model 
and  its  preprocessor  which  are  known  by  NBS  project  staff  to  be  machine 
dependent,  and  hence  to  require  possible  alteration  when  DELCAP  is 
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converted  to  another  computer.  Others  may  come  to  light  during  the 
conversion  process.  It  was  known  during  the  design  and  development 
stages  that  the  model  might  be  converted  to  other  machines,  and  this 
fact  was  taken  into  consideration  in  designing  the  model;  hence  the 
conversion  process  should  be  less  difficult  than  if  conversion  had  been 
an  afterthought. 

The  next  two  appendices  contain  mathematical  derivations  of  two 

\ 

formulas  used  in  the  DELCAP  simulation.  The  final  appendix  contains 
a copy  of  a Mock  Instruction  Manual  for  the  DELCAP  model  as  it  is 
envisioned  to  operate  in  its  final  form. 

We  conclude  this  section  by  listing  the  project  staff  involved 
in  the  DELCAP  effort: 

Operations  Research  Section  (Applied  Math  Division) 

J.  Gilsinn  (Project  Leader) 

D.  Klavan 

Mathematical  Modeling  Group  (Technical  Analysis  Division) 

E.  Short 
W.  Steele 

In  addition  to  those  listed  above,  R.  Penn  of  the  Technical 
Analysis  Division  and  A.  J.  Goldman  of  the  Applied  Mathematics 
Division  provided  valuable  criticism  and  guidance  in  the  course  of 
the  model  design  and  development. 
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2.  FUNCTIONAL  DESCRIPTION  OF  THE  MODEL 


2.1  General  Description 

The  DELCAP  simulation  model  is  designed  to  provide  measures  of 
throughput  and  user  delays  for  a variety  of  teminal-area  scenarios 
which  can  be  characterized  by 

(a)  airport  runway  configurations  and  operation  modes 

(b)  mixes  of  aircraft  types,  and 

(c)  separation  rules. 

It  is  intended  to  handle  primarily  IFR  operations,  and  so  the 
rules  referred  to  in  section  (c)  above  may  be  interpreted  as  IFR 
separation  rules. 

DELCAP  is  envisioned  as  a planning  and  analysis  tool  for  use 
in  investigating  the  effects  on  throughput  and  delay  of  changes 
in  any  of  (a),  (b),  and/or  (c) . It  is  not  designed,  for  instance, 
to  provide  controller  work- load  information  or  to  output  gate 
assignments  for  various  airlines.  It  is  designed  to  aid  in  answering 
questions  such  as,  ’’Can  the  present  configuration  at  a given  airport 
handle  an  increase  of  501  in  traffic?”,  or  "Would  delay  be  decreased 
by  reserving  one  runway  for  large  and  medium  size  jets  and  large 
piston  aircraft?”.  In  accordance  with  the  "model  as  little  as  you 
can”  philosophy  described  in  Chapter  1,  DELCAP  has  a limited  scope 
and  limited  application.  It  is  designed  to  be  used  in  planning 
for  next  year  or  several  years  hence,  rather  than  planning  day-to-day 
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operations.  It  can  be  used  to  examine  the  effects  on  the  level 
of  congestion  of  adding  extra  runways,  or  of  reducing  required  IFR 
separation.  It  cannot,  however,  answer  the  much  more  difficult 
question  of  how  safe  a current  or  proposed  procedure  is . It  is 
envisioned  as  only  one  part  of  the  planning  process,  a tool  to  be 
used  by  the  planner  rather  than  an  end  in  itself. 

Because  DELCAP  has  the  rather  limited  aim  of  providing  measures  of 
delay  and  throughput,  it  does  not  have  to  simulate  in  detail  the  path 
flown  by  each  aircraft.  All  that  need  be  represented  in  detail 
are  those  aspects  of  the  flight  of  an  aircraft  which  impede  the 
free  progress  of  other  aircraft.  If  one  aircraft  is  holding  up  a 
second,  which  thereby  holds  up  a third,  etc.,  it  is  necessary  only 
to  simulate  the  first  and  to  accumulate  correctly  the  total  effects 
on  the  others. 

Since  in  DELCAP  we  are  interested  only  in  delay  and  throughput, 
it  is  not  necessary  to  know  exactly  where  a delayed  aircraft  actually 
is  during  the  delay  period.  It  may  be  sitting  in  a line  on  a taxiway, 
or  waiting  at  its  gate.  It  may  be  flying  a full  race -track -like  holding 
pattern,  or  just  a U-shaped  curve.  Our  implicit  assumption  in  the 
current  version  of  DELCAP  is  that  aircraft  are  under  control  and 
can  be  delivered  to  the  ILS  gate  for  landing  or  to  the  end  of  the 
runway  for  takeoff,  as  soon  as  separation  rules  allow. 

[This  "perfect  control"  assumption  is  necessarily  somewhat 
optimistic.  It  can  be  tempered  by  adjoining,  to  the  model,  appropriate 
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probability  distributions  for  time  increments  representing  the 
deviations  from  "earliest  possible  delivery  time"  which  reflect 
less -than -perfect  control  by  controllers  and/or  pilots.  Such 
"Monte  Carlo"  elements  have  been  postponed  in  our  initial 
development  work  in  favor  of  concentrating  on  the  basic  model  logic,] 

DELCAP  is  a terminal-area  simulation.  Landings  enter  the  model 
approximately  at  handoff  to  tower  approach  control  ? and  leave  it  as 
they  turn  off  the  runway.  Takeoffs  enter  the  model  approximately  15 
minutes  before  departure,  and  leave  at  handoff  to  center  control. 

The  present  version  of  DELCAP  does  not  deal  with  on-the-ground 
activities  except  for  the  actual  landing  or  takeoff  on  the  runway. 

Its  "accounting"  includes  a figure  representing  the  time  needed  for 
a takeoff  to  depart  its  gate  and  taxi  to  the  runway,  but  variations 
in  this  time  due  to  taxiway  and/or  ramp  congestion  are  not  now 
modeled.  In  short,  the  priority  decisions  required  by  time  and 
budget  limits  have  led  to  heavy  emphasis  on  airborne  activities 
in  this  generation  of  DELCAP,  with  extension  to  ground  activities 
seen  as  a natural  "growth  step"  requiring  more  care  and  deliberation 
than  was  available  as  a "residual"  in  our  present  study. 

The  acronym  "DELCAP"  stands  for  DELay  CAPacity,  the  two 
items  the  simulation  was  designed  to  measure.  Delay  is  a user 
disutility  while  capacity  is  in  some  sense  a system  utility. 

The  decision  as  to  the  proper  balance  between  these  two  is  a policy 
issue,  and  involves  a variety  of  considerations  relating  to  limitations 
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on  ’’system’'  budgets  and  personnel,  value -of -time  for  operators  and 
passengers,  etc.  The  DELCAP  model’s  role  in  this  whole  planning 
process  is  to  aid  by  translating  FM  rules,  decisions,  and  airport 
configuration  and  operation  changes  into  delay  and  throughput  figures. 

Since  the  scope  of  the  model  is  much  less  than  the  full  gate-to-gate 
span  of  a flight,  the  delay  estimated  in  the  DELCAP  model  is  only  a 
portion  of  the  total  delay  experienced  by  an  air  passenger.  Specifically, 
it  is  that  portion  of  delay  which  may  be  affected  by  changes  in(a) , (b) , 
or  (c)  of  page  7.  Delay  is  measured  as  the  difference  between  (i)  the 
time  in  an  ideal  scenario,  in  which  the  present  landing  or  takeoff  is 
the  only  aircraft  using  that  terminal,  and  (ii)  the  time  in  the  real 
situation  where  other  planes  may  simultaneously  be  seeking  to  use  the 
area. 

For  a landing,  the  time  under  the  ideal  scenario  is  a sum  of: 

A minimum  flying  time  from  handoff  to  the  outer  marker  of  the  desired 
landing  runway;  a time  to  fly  the  final  approach  path;  and  a runway 
occupancy  time.  The  ’’real”  scenario  as  simulated  by  DELCAP  may  include 
an  additional  time  period  (possibly  zero)  between  handoff  and  the 
outer  marker  to  account  for  other  aircraft  landing  before  this  one. 

This  period  arises  as  follows.  At  handoff  the  aircraft  is  filed  in  a 
waiting  queue.  When  the  time  comes  that  the  aircraft  could  have 
reached  the  outer  marker  in  the  absence  of  other  aircraft,  the  queue 
and  the  final  approach  path  are  examined.  If  there  are  other  aircraft 
before  this  one  in  the  aueue,  it  must  wait  until  it  is  finally  at  the 
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head  of  the  line.  Then  the  ’’current  obligations”  of  its  final  approach 
path  and  runway  are  examined  to  determine  when  this  aircraft  could  first 
cross  the  outer  marker  and  proceed  down  the  final  approach  path  with- 
out violating  separation  rules.  The  delay  to  this  aircraft  is  then 
the  difference  between  (i)  when  it  could  have  left  the  queue  were 
there  no  other  aircraft  interfering  with  it,  and  (ii)  the  actual  time 
it  was  able  to  leave  the  queue.  A similar  process  applies  to  a takeoff. 

The  ’’capacity”  measured  by  the  DELCAP  model  is  actual  throughput, 
the  number  of  operations  (landings  plus  takeoffs)  performed  in  a 
given  unit  of  time  (e.g.,  an  hour  or  a day).  This  kind  of  ’’capacity” 
measure  differs  from  the  common  definition  of  capacity.  The  capacity 
of  a jug  is  the  amount  of  liquid  the  jug  can  hold.  This  represents 
the  absolute  limit  for  the  jug,  j.ust  this  much  and  no  more.  The 
definition  of  capacity  used  in  the  FAA’s  Airport  Capacity  Handbook  [4] 
refers  to  the  maximum  traffic  rate  which  can  be  handled  without  average 
delay  exceeding  a prescribed  level.  Previous  work  by  NBS  [6]  offered 
an  alternative  to  this  definition,  based  on  a definition  of  capacity 
as  maximum  mean  throughput  rate. 

The  DELCAP  model’s  capacity  is  a throughput  measure  more  akin 
to  this  last  than  to  that  contained  in  the  Airport  Capacity  Handbook. 

It  differs  from  the  previous  NBS  work  in  one  significant  respect  -- 
it  is  not  a maximum  possible  throughput  rate.  Rather  it  is  that 
throughput  rate  achievable  from  a given  distribution  of  traffic  over 
the  day  (or  other  simulated  time  period).  If  traffic  is  light,  throughput 
will  be  small.  As  traffic  increases  to  a level  which  saturates  the  airport, 
mean  throughput  will  approach  the  NBS-defined  capacity.  In  busy  periods 
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the  airport  throughput  will  be  close  to  capacity;  as  peak  traffic 
levels  pass  to  lower  values,  throughput  will  decrease.  As  traffic 
fluctuates,  resultant  delay  will  fluctuate,  and  both  will  be  recorded 
by  DELCAP.  Thus  DELCAP  records  the  throughput  resulting  from  a given 
temporal  traffic  distribution. 

The  DELCAP  simulation  is  a critical -event  model.  That  is,  within 
the  simulation,  time  is  successively  advanced  from  its  current  value 
to  that  of  the  "next  significant  event”,  rather  than  being  stepped 
along  in  uniform  increments.  For  periods  with  a low  traffic  level, 
this  type  of  model  saves  much  computation.  Even  during  periods  of 
high  density  traffic,  such  a simulation  does  not  increase  the 
number  of  calculations  required.  The  SIMSCRIPT  simulation  language 
is  designed  for  the  critical  event  type  of  simulation.  The  modeler 
need  only  provide  suitable  descriptions  of  each  type  of  critical  event, 
including  how  these  events  depend  upon  one  another.  The  SIMSCRIPT 
code  then  executes  the  events  in  chronological  order.  The  critical 
events  for  the  DELCAP  system  are  illustrated  in  Figure  2.1.1.  This 
figure  is  in  the  form  of  a flowchart  because  it  illustrates  the  idealized 
progression  of  events.  ’’Idealized”  is  used  here  to  refer  to  the  order 
of  events  as  they  occur  for  a single  aircraft,  without  events  for  other 
aircraft  interspersed  among  them.  This  is  not  necessarily  the  order  in 
which  the  events  occur.  As  an  example,  two  hypothetical  flights  and  an 
illustrative  list  of  the  critical  events  for  each  are  given  in  Figure  2.1.2. 
The  order  in  which  the  events  would  actually  be  performed  by  the  simulation  is 
given  in  Figure  2.1.3.  Two  events  happen  to  occur  at  9:17;  the  order  of 
these  two  is  inmaterial . 
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Figure  2.1.1:  DELCAP  Critical  Events  (Relative  to  a Single  Aircraft) 
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FLT  1 : 


(1) 

(2) 

(3) 

(4) 
C5) 


Landing  on  runway  1 

9:00  - FLT  1 enters  the  system. 

9:12  - FLT  1 has  flown  to  outer  marker;  find  next  operation  on 
runway  1 (assume  next  is  FLT  1)  . 

9:13  - FLT  1 has  started  down  flight  path; 

find  next  operation  on  runway  1 (none) 

9:16  - FLT  1 has  flown  down  final  approach  path,  FLT  1 lands. 
9:17  - FLT  1 leaves  the  system  after  occupying  the  runway. 


FLT  2 : Takeoff  on  runway  2 

(1)  9:05  - FLT  2 enters  the  system. 

(2)  9:15  - FLT  2 leaves  gate;  begins  taxiing  to  runway  2; 

find  next  operation  on  runway  2 

(3)  9:17  - FLT  has  been  given  clearance  to  takeoff; 

find  next  operation  on  runway  2 (none) . 

(4)  9:18  - FLT  2 takes  off. 

(5)  9:23  - FLT  2 is  handed  off  to  center  control;  FLT  2 leaves  the 

system. 


Figure  2.1.2: 


Illustrative  List  of  Critical  Events  for  Two  Flights 


9:00  FLT  1 
9:05  FLT  2 
9:12  FLT  1 
9:13  FLT  1 
9:15  FLT  2 
9:16  FLT  1 
9:17  FLT  2 
9:17  FLT  1 
9:18  FLT  2 
9:23  FLT  2 


(1)  enters  the  system 

(1)  enters  the  system 

(2)  find  next  operation  on  runway  1 

(3)  find  next  operation  on  runway  1 

(2)  find  next  operation  on  runway  2 

(4)  land 

(3)  find  next  operation  on  runway  2 

(5)  leaves  the  system 

(4)  takeoff 

(5)  leaves  the  system 


Figure  2.1.3:  Actual  Order  of  Occurrence  of  Critical  Events  for 

Illustrative  List 
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The  basic  concept  around  which  the  DELCAP  simulation  model  is 

built  is  that  of  tieup.  The  presence  of  one  aircraft  limits  the  actions 

which  another  controlled  aircraft  may  take.  For  example,  present  FAA 

separation  rules  require  any  IFR  landing  aircraft  to  be  separated  by 

3 miles—'  from  other  landing  aircraft  and  2 miles  from  preceding  takeoffs 

on  the  same  runway;  other  restrictions  apply  between  takeoffs.  Parallel 

runways  have  special  rules,  depending  on  how  far  apart  the  center  lines 

for  the  parallel  runways  are.  These  various  separation  rules  are  imposed 

in  the  model  by  declaring  certain  points  traversed  by  an  aircraft  to 

be  off  limits  ("tying  up"  those  points)  to  all  subsequent  aircraft 

for  a period  sufficiently  long  to  insure  that  the  required  separation 

is  maintained.  In  the  present  version  of  DELCAP,  tieups  can  occur 

at  one  of  three  such  points  associated  with  each  runway.  Two  pertain 

to  landings,  namely  the  outer  marker  and  the  runway  threshold;  the 

third,  which  refers  to  takeoffs,  is  the  point  at  the  end  of  the  runway 

2/ 

from  which  a takeoff  starts  its  roll.— 

3/ 

The  3-mile  separation— ' between  successive  landings  is  enforced, 

either  by  tying  up  the  outer  marker  from  the  time  the  first  aircraft 

crosses  it  until  the  second  has  flown  three  miles,  or  by  tying  up  the 

runway  threshold  from  the  time  the  first  aircraft  has  landed  until  the 

second  has  flown  3 miles.  (Which  of  these  alternatives  applies  depends 

on  the  relative  landing  speeds  of  the  two  planes.) 

T/  All  distances  referred  to  in  this  report  are  in  nautical  miles 
Speed  will  therefore  be  in  knots. 

2/  Throughout  the  remainder  of  this  report,  the  term  "end  of  runway" 
will  be  used  to  designate  this  point.  It  and  the  runway  threshold 
are  assumed  to  represent  approximately  the  same  physical  point  on  the 
runway. 

3/  The  3-mile  value  and  the  values  for  the  other  separation  distances 
are  adjustable  parameters  in  the  simulation  model. 
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The  other  separation  rules  are  imposed  in  a similar  manner.  The 

prohibition  against  more  than  one  aircraft  being  on  the  same  runway 

at  the  same  time  is  enforced  by  tying  up  the  runway  threshold  and  the 

end  of  the  runway  for  the  entire  time  a landing  or  takeoff  occupies 

the  runway.  Interference  between  operations  on  intersecting  runways 

can  also  be  represented  by  the  tieup  concept:  the  end  and  threshold 

of  a runway  are  tied  up  from  the  time  an  aircraft  on  an  intersecting 

runway  starts  its  roll  or  touches  down  until  it  clears  the  intersection. 

Interference  between  successive  landings  on  parallel  runways  3500 

to  5000  feet  apart  can  be  portrayed  by  appropriately  tying  up  the  outer 

marker  or  the  runway  threshold  of  both  runways. 

The  separation  required  between  a pair  of  departing  aircraft 

depends  on  the  particular  paths  followed  by  the  two  aircraft  after 

departure.  If  they  diverge  immediately  only  a 1 -minute  separation 

is  required,  if  within  five  miles  then  a 2 -minute  separation  is  called 
4/ 

for,  etc.—  All  but  one  of  these  separation  rules  are  in  terms  of  time; 
the  exception,  a distance  separation  (3  mi.),  is  converted  to  the  weighted 
average  (over  aircraft  types)  of  the  time  to  fly  that  distance.  Each 
takeoff  is  associated  with  a departure  path  when  it  first  enters  the 
model.  The  simulation  assumes  that  aircraft  diverge  as  soon  as  their 
departure  paths  diverge.  Thus  the  separation  required  between  two 

£/  See  Terminal  Air  Traffic  Control  (FAA  7110. 8A)  for  a complete 
description  of  these  rules. 
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takeoffs  from  the  same  runway  depends  solely  on  the  pair  of  departure 
paths  involved.  An  analogous  second  set  of  values  for  separation  times 
applies  to  takeoffs  on  different  runways.  (This  procedure  for  simulating 
separation  between  succeeding  takeoffs  is  an  approximation  which  may 
merit  refinement  in  later  work.) 

Two  final  considerations  will  be  emphasized  in  this  overview. 

First,  in  keeping  with  the  design  of  DELCAP  as  a planning  tool,  it 
is  necessary  that  the  simulation  be  fast  to  operate,  while  representing 
enough  of  the  system  to  provide  usable  delay  and  throughput  figures. 

The  current  DELCAP  has  been  run  to  simulate  a day's  activity  (about  1000 
operations)  at  an  airport  with  the  runway  configuration  of  New  York's 
JFK;  this  took  about  12  seconds  on  the  UNI  VAC  1108  compute  r.  (The 
time-figure  includes  the  time  required  for  reading  input  data,  but  not 
that  for  program  compilation.)  It  seems  clear  that  with  this  speed, 
computer-cost  and  running-time  considerations  should  not  deter  a 
planner  from  analyzing  the  full  "reasonable"  range  of  cases  of 
interest  to  him. 

Besides  being  fast,  DELCAP  must  also  be  easy  to  operate  if  it  is 
to  be  useful  as  a planning  and  analysis  tool.  The  most  time-consuming 
and  laborious  task  in  running  any  simulation  is  preparing  the  input. 

Both  the  job  of  collecting  the  information  (if  it  is  not  readily  available) 
and  that  of  formatting  it  in  computer -readable  form  can  be  difficult, 
indeed  forbidding.  These  problems  were  recognized  in  the  design  of  the 
DELCAP  model.  The  simulation  itself  is  written  in  SIMSCRIPT,  which 
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requires  a rather  awkward  and  rigidly  prescribed  input  format.  To 
overcome  this,  a FORTRAN  preprocessing  program  was  written.  This 
program  accepts  input  in  a more  easily  prepared  format  and  was 
specifically  designed  to  make  a user's  task  less  laborious.  Data 
are  grouped  into  six  categories.  The  user  m^  specify  any  or  all  of  these 
categories,  or  may  elect  not  to  specify  a category,  thereby  accepting  a 
standard  set  of  values  for  that  category.  At  present  the  configurations 
for  two  airports  (ATL  and  JFK)  are  available  as  "standard"  sets. 

Other  airports  may  be  included  by  assembling  the  necessary  data  and  adding 
them  to  the  input  tape. 

The  six  data  categories  are: 

1.  parameters  describing  each  type  of  aircraft,  such  as  landing  and 
liftoff  speeds  and  runway  occupancy  times, 

2.  mix  of  aircraft  types  using  the  terminal  area, 

3.  number  of  aircraft,  desiring  landings  and  takeoffs 
respectively,  to  enter  the  model  for  each  hour  of  the  day, 

4.  separation  rules, 

5.  description  of  the  airport  configuration  and  operation,  and 

6.  distribution  of  runway  use  by  aircraft  type,  separately  for  landings 
and  takeoffs . 

Standard  values  for  1 and  4 are  independent  of  the  airport,  while  standard 
values  for  each  of  the  other  four  categories  are  provided  for  each  airport 
in  the  airport  data  list.  A user  need  specify  only  those  data  which  he 
wishes  to  differ  from  standard  values,  plus  the  airport  identifier  for  the 
standard  values  which  depend  an  airport.  This  policy,  of  data  input 
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?Tby  exception”  to  a standard  data  set,  facilitates  ease  of  input  while  still 
allowing  full  flexibility. 

This  concludes  our  overview  of  the  DELCAP  model  and  of  the  design 
criteria  under  which  it  was  built.  The  next  section  will  describe  in 
greater  detail  how  DELCAP  simulates  terminal-area  activities.  Its 
preprocessor  will  be  described  in  the  following  section. 
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2.2  Specific  Description  of  Simulation  Model 


To  explain  the  operation  of  the  DELCAP  model  in  further  detail, 
we  will  in  this  section  "fly”  a hypothetical  aircraft  through  the 
simulation,  describing  hew  its  progress  is  represented  by  the  various 
elements  of  the  model.  The  next  chapter  describes  in  detail  the 
computer -program  implementation  of  this  procedure.  Here,  our  aim  is 
a functional  description  of  the  simulation,  rather  than  a computer- 
oriented  view. 

Figure  2.2.1  describes  the  critical  events  which  occur  to  a single 
aircraft : 

1 . generation  of  flight, 

2.  sequencing  of  operations  on  a runway, 

3.  maintain  separation,  and 

4.  land  or  takeoff. 

A landing  aircraft  enters  the  system  at  handoff.to  tower  approach  control 
and  is  filed  in  a landing  queue  (for  its  runway)  in  which  it  remains  until 
the  minimum  time  to  fly  from  handoff  to  the  outer  marker  has  elapsed. 

The  next  event  which  affects  this  aircraft  is  the  choice,  depending  on 
the  operational  procedure  for  its  particular  runway,  of  the  next 
operation  ( a takeoff  or  a landing)  which  is  to  occur  on  this  runway. 

Once  the  aircraft  has  come  to  the  head  of  the  queue  and  the  next  operation 
is  a landing,  the  model  must  ensure  that  the  aircraft  does  not  violate 
any  separation  rules  pertaining  to  it.  Finally  it  is  removed  from 
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the  queue,  is  scheduled  to  land,  and  the  relevant  points  are  tied  up 
to  ensure  that  other  aircraft  will  remain  separated  from  it. 

A takeoff  enters  the  system  about  15  minutes  before  departure 
as  scheduled  in  a filed  flight  plan  and  at  this  time  is  filed  in  a 
queue  in  which  it  remains  until  a few  minutes  before  scheduled  takeoff. 
Mien  the  flight  has  reached  the  head  of  the  queue  and  the  next  operation 
to  be  scheduled  is  a takeoff,  the  flight  is  removed  from  the  queue, 
and  is  scheduled  to  takeoff  as  soon  as  possible  while  maintaining 
required  separation.  Once  it  has  been  scheduled  relevant  points  are 
tied  up  to  ensure  other  aircraft  are  separated  from  it. 

The  rest  of  this  section  will  describe  each  of  these  four 
critical  events  in  greater  detail. 

2.2.1  Flight  Generation 

Aircraft  enter  the  simulation  in  two  ways,  one  stochastic  and  the 
other  deterministic.  In  any  one  simulation  run,  either  or  both  methods 
may  be  used.  In  the  stochastic  form,  aircraft  are  generated  in  a Poisson 
manner.  (Employment  of  this  particular  distribution  is  somewhat 
arbitrary,  and  it  can  be  replaced  by  a different  one  if  found  more 
appropriate.)  The  use  of  a Poisson  distribution  in  effect  assumes 
that  the  probability  of  the  arrival  of  an  aircraft  in  the  system  at 
any  time  is  independent  of  any  previous  arrivals. 

Such  randomness  may  be  an  appropriate  representation  for  low  or 
moderate  traffic  densities.  In  a highly  saturated  air  traffic  system, 
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however,  congestion  in  terminal  areas  is  felt  in  other  sectors  as  well. 
Since  IFR  traffic  is  under  control  from  takeoff  to  landing,  traffic 
patterns  are  in  fact  not  random.  Wien  a terminal  area  becomes 
saturated,  flights  destined  for  this  terminal  may  be  held  up  at 
distant  points  and  handed  off  to  the  terminal  area  only  as  a slot 
in  a stack  becomes  available.  This  extreme  case,  almost  diametrically 
opposite  to  Poisson  randomness,  represents  a nearly  uniform  distribution 
of  arrivals  into  the  terminal -area  landing  pattern. 

A similar  situation  may  exist  with  regard  to  takeoffs:  the 

arrival  of  a takeoff  in  the  "system"  is  about  15  minutes  before 
departure  as  scheduled  by  filed  flight  plan,  but  in  actual  practice 
when  the  flight  plan  is  filed  the  pilot  can  be  advised  of  expected 
delay  and  may  revise  his  flight  plan.  The  simulation  deals  only  with 
revised  plans,  which  in  heavy  traffic  would  tend  to  exhibit  a less 
random  behavior. 

The  particular  form  of  Poisson  generation  used  in  DELCAP  does 
allow  representation  of  the  diurnal  peaking  of  traffic  density. 

The  user  can  specify  both  the  mean  number  of  landing  aircraft  to  be 
generated  for  each  hour  of  the  day,  and  the  mean  number  of  takeoffs. 

The  expected  time  (as  a fraction  of  an  hour)  between  generation  of 
successive  takeoffs  or  landings  is  computed  as  the  reciprocal  of 
the  number  of  takeoffs  or  landings  entering  the  system  per  hour. 

If  the  next  scheduled  landing  or  takeoff  to  be  generated  enters 
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the  system  in  the  next  hour,  it  is  rescheduled  according  to  the 
generation  rate  for  the  proper  hour.  This  avoids  a situation 
such  as  the  following: 

(a)  Hour  1 has  1 landing  per  hour. 

(b)  Hour  2 has  12  landings  per  hour. 

fc)  Flight  1 is  generated  (hay)  at  1:30;  Flight  2 is 

then  scheduled  (say)  for  2:30  on  the  basis  of  the  Ml-hour 
spacing"  rule  still  in  force  at  1:30. 

If  the  simulation  were  really  to  wait  until  2:30  to  start  generating 
flights  an  average  of  five  minutes  apart,  then  the  expected  number  of 
flights  for  Hour  2 would  be  only  half  as  large  as  it  should  be.  The 
rescheduling  procedure  described  above  can  be  shown  to  provide  the 
correct  expected  number  of  landings.  For  the  preceding  example, 
flight  2 would  initially  be  scheduled  for  2:30.  At  2:00,  however,  it 
would  be  rescheduled  using  the  expected  time  until  the  next  landing 
as  5 minutes.  Subsequent  flights  would  continue  to  use  this  5-minute 
figure  until  some  flight  was  scheduled  for  Hour  3.  At  3:00,  this 
flight  would  be  rescheduled,  and  so  on. 

A second,  deterministic  method  of  generating  flights  is  available. 
The  simulation  may  be  provided  (on  a magnetic  tape  or  on  cards)  with 
a list  of  landings  and  takeoffs  in  the  order  of  their  entries  to  the 
system.  This  form  of  traffic  generation  may  be  used  either  instead  of 
or  in  conjunction  with  the  Poisson  generation  described  above.  For 
example,  scheduled  air  carrier  flights  might  be  input  in  a deterministic 
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fashion  while  unscheduled  flights  could  be  generated  by  the  Poisson 
process,  fit  should  be  noted  that  in  this  case  the  input  values 
of  the  expected  numbers  of  landings  and  takeoffs  for  the  Poisson 
process  should  reflect  unscheduled  traffic  levels  only,  not  the 
combination  of  both.) 

We  should  emphasize  here  that  in  a computer,  the  stochastic  form 
is  ’’pseudo -random”  rather  than  truly  random.  If  the  same  starting 
number  (’’seed)  for  the  computer’s  pseudo -random-number  generating 
routine  is  used  in  two  runs,  exactly  the  same  sequence  of  ’’random” 
numbers  will  occur.  Therefore  the  stochastic  mode  of  traffic 
generation  provides  a repeatable  traffic  sample,  which  may  properly 
be  used  in  comparing  various  alternatives.  If  however  the  expected 
number  of  landings  or  takeoffs  per  hour  is  changed  between  two  runs, 
then  different  traffic  samples  will  occur. 

Each  flight  which  enters  the  system  is  (1)  designated  as  either  a 
landing  or  a takeoff,  (2)  associated  with  a specific  runway,  (3) 
identified  as  of  a particular  aircraft  type  category,  and  if  a departure, 
(4)  assigned  to  a particular  departure  path.  In  the  stochastic 
generation  process  these  selections  are  made  through  a random  process, 
while  for  deterministically  generated  flights  they  are  read  in  as  part 
of  the  flight  description.  For  the  stochastic  process,  the  simulation 
must  be  provided  with  (1)  one  distribution  of  aircraft  types  for  landings 
and  a second  one  for  takeoffs,  f2)  the  distribution  of  runway  use  by 
aircraft  type  for  landings  and  also  for  takeoffs,  and  finally 
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C3)  the  distribution  of  departure  paths  for  aircraft  using  each 
runway.  As  a flight  is  generated,  the  appropriate  distributions 
are  sampled  to  assign  to  it  a type,  a runway  and  (if  it  is  a 
takeoff)  a departure  path. 

[It  should  be  clear  from  the  description  of  this  process,  that  the 
runway  choice  is  not  influenced  by  the  traffic  levels  of  the  various 
runways  at  the  time  of  generation.  That  is,  the  runway-use  distribution 
presently  can  reflect  only  general  traffic  levels  for  each  runway;  this 
distribution  is  not  altered  within  the  simulation,  remaining  constant 
throughout.  Permitting  such  "adaptive”  alterations  would  require  only 
a fairly  minimal  change  in  the  DELCAP  model,  but  the  user  would  then 
have  to  specify  those  "threshold"  traffic  levels  at  which  a change  in 
runway  assignment  would  be  encouraged.] 

After  a flight  is  generated  and  has  received  its  proper  runway, 
type,  and  departure  path  assignments,  it  is  placed  into  a queue  of 
aircraft  waiting  to  land  or  takeoff  from  its  assigned  runway.  There 
are  two  separate  queues  for  each  runway,  one  for  takeoffs,  and  another 
for  landings.  These  queues  are  organized  in  a first-in  first-out 
(FIFO)  manner.  This  means  that  aircraft  which  are  to  land  on  a particular 
runway  land  in  the  order  in  which  they  enter  the  system,  regardless  of 
speed  or  category  of  aircraft.  It  does  not  mean,  however,  that 
aircraft  landings  on  different  runways  (or  landings  and  takeoffs  on 
the  same  runway)  occur  in  the  order  in  which  they  entered  the  system. 
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This  first-come  first-served  process  models  the  presently  stated 
control  policy.  To  model  a more  sophisticated  sequencing  policy,  the 
queues  could  instead  be  ordered  based  on  some  attribute  such  as  type 
classification  or  flight  priority  level.  (SIMSCRIPT  list  structure 
allows  such  changes  with  a minimal  amount  of  recoding.) 

Landings  remain  in  the  queue  for  at  least  the  minimum  time  for 
that  type  of  aircraft  to  fly  from  handoff  to  the  outer  marker  of  the 
proper  runway.  Takeoffs  are  generated  about  15  minutes  before 
planned  departure  and  are  filed  into  the  queue  at  this  time. 
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2.2.2  Operation  Sequencing 


The  next  section  of  the  simulation  which  affects  our  hypothetical 
flight  is  the  routine  which  sequences  operations  on  runways.  If  for 
example  our  aircraft  is  to  land  on  "runway  R",  then  it  can  move  up  in  its 
queue  only  when  this  routine, applied  to  runway  R,  selects  the  lead 
operation  of  that  runway’s  landing  queue  rather  than  its  takeoff  queue. 

There  are  four  different  operational  procedures  which  govern 
whether  the  next  aircraft  to  use  the  runway  in  question  will  be  a 
landing  or  a takeoff.  Runways  may  be  restricted  to  landings  only  or 
takeoffs  only.  In  either  of  these  two  cases  the  simulation  will  schedule 
the  next  operation  of  the  permitted  type  if  one  is  available. 

The  last  two  procedures  apply  to  dual-use  runways  (used  for 
both  landings  and  takeoffs),  and  are  slightly  more  complicated.  The 
first  of  them  seeks  to  alternate  landings  and  takeoffs  during  heavy 
traffic  periods  (and  to  take  the  first  available  operation  otherwise). 

If  the  last  operation  was  a takeoff,  for  instance,  then  the  landing  queue 
is  examined.  If  the  first  flight  in  it  will  be  available  when  the  runway 
and  final  approach  path  are  next  free,  then  that  landing  is  designated  as 
the  next  operation  on  this  runway.  However,  if  the  landing  queue  is 
empty  or  the  first  aircraft  in  it  will  not  be  immediately  available,  the 
takeoff  queue  is  examined.  If  the  first  flight  in  the  takeoff  queue  will  be 
available  immediately,  it  is  designated  as  the  next  operation.  But 
if  neither  landing  nor  takeoff  will  be  available  immediately,  the  one  which 
will  be  available  first  is  chosen.  (Of  course  if  there  are  no  aircraft  at  all 
in  either  queue  to  use  this  runway  at  the  time,  then  no  "next  operation" 
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is  schedule  c1,) 

The  fourth  procedure  attempts  to  model  the  "landings  take  precedence" 
rule.  This  procedure  is  very  similar  to  the  one  described  above  for 
alternating  operations,  except  that  the  landing  queue  is  always  examined 
first.  If  the  first  landing  is  available  immediately  then  it  is  assigned 
as  the  next  operation.  If  not,  then  that  operation  (landing  or  takeoff) 
which  would  first  be  available  becomes  the  next  operation.  At  present 
the  model  provides  no  method  to  change  the  operational  procedure  for  a 
runway  during  the  simulation,  although  it  would  require  only  a minimal 
change  to  do  so.  The  user  would  then  be  required  to  specify  the  conditions 
or  times  for  which  this  should  occur. 

2.2.3  Maintain  Separation 

The  next  block  of  the  model  which  affects  our  hypothetical  flight 
is  the  section  which  insures  that  required  separations  are  maintained. 
Relevant  when  the  flight  reaches  the  head  of  its  designated  runway’s 
landing  or  takeoff  queue,  this  routine  finds  the  first  time  the  flight 
can  land  (or  takeoff)  on  that  runway.  For  takeoffs  the  end  of  the 
runway  is  examined,  and  the  flight  is  allowed  to  start  its  roll  as 
soon  as  this  point  is  free  (no  longer  tied  up) . For  landings  both  the 
outer  marker  and  the  runway  threshold  are  examined,  since  a landing  must  pass 
both  of  these  points:  Let  t1  be  the  time  at  which  the  outer  marker  will  be 

free  (no  further  tieups  for  it  are  currently  known) , and  t2  the 
corresponding  time  for  the  runway  threshold.  Let  T be  the  time  it  takes 
this  flight  to  fly  the  final  approach  path  from  the  outer  marker 
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to  the  runway  threshold.  Then  the  flight  may  start  to  fly  down  the 
final  approach  path  at  whichever  of  t^  and  t ^ ~T  is  later. 

Several  tieups  may  be  in  force  at  any  of  the  three  points: 
outer  marker,  runway  threshold  and  the  end  of  the  runway.  The 
model  always  forces  an  aircraft  to  wait  until  there  are  no  currently 
known  tieups  applicable  along  its  path,  even  though  theoretically  there 
might  be  a gap  between  tieups  sufficiently  large  to  allow  fitting  an 
operation  between  two  previously  scheduled  ones.  That  this  is  an 
infrequent  event  in  practice  depends  on  the  fact  that  in  the  model 
takeoffs  and  landings  are  scheduled  approximately  the  same  time 
before  touchdown  and  start-of-roll  respectively.  For  any  runway 
the  takeoffs  are  scheduled  in  the  order  in  which  they  are  generated, 
and  similarly  for  landings.  The  sequencing  routine  takes  care  of 
the  order  of  operations  on  any  one  runway  and  takes  into  account 
the  times  at  which  those  operations  can  occur.  Therefore  the  only 
case  in  which  a flight  might  be  squeezed  in  between  two  tieups  would 
involve  inserting  that  flight  before  a tieup  caused  by  a flight  which 
has  been  previously  scheduled  on  another  runway.  This  circumstance 

is  unlikely  to  occur  except  in  the  situation  of  a slow  landing  which 
has  just  started  down  the  flight  path  on  one  runway  and  a fast  takeoff 

which  could  take  off  on  a second  runway  and  remain  safely  separated 
from  the  landing. 

Allowing  in  the  simulation  for  such  "insertions”  would  require 
major  complication  of  the  model  logic.  Granting  that  the  situation 
wiH  seld°m  occur  (indeed  we  have  only  seen  it  once  or  twice  in  our 


-30- 


debugging  runs) , its  overall  effect  on  aggregate  measures  of  capacity 
and  delay  is  minimal.  On  this  basis,  it  was  decided  that  the  extra 
complication  would  be  unwarranted. 

2.2.4  Land  or  Take  Off 

Finally,  our  hypothetical  flight  is  ready  to  land  or  take  off.  In 
the  simulation  this  process  essentially  consists  of  tying  up  the  appropriate 
points  to  ensure  that  "following"  aircraft  maintain  required  separation 
from  the  given  one.  "Following"  is  used  here  to  refer  to  those  flights 
whose  landing  or  takeoff  is  scheduled  after  the  current  one.  In  crder 
to  maintain  the  required  separation  between  landings  either  the  outer 
marker  (if  the  following  landing  is  slower)  or  the  runway  threshold 
(if  the  following  landing  is  faster)  is  tied  up  from  the  time  the 
current  flight  passes  that  point  until  the  second  flight  has  flown 
the  separation  distance.  Both  the  runway  threshold  and  the  end  of  the 
runway  are  tied  up  for  the  period  the  current  aircraft  occupies  the 
runway.  A landing  ties  up  the  end  of  the  runway,  and  a takeoff  the 
runway  threshold,  for  a time  period  sufficient  to  maintain  the  separation 
between  a takeoff  and  a following  landing.  (The  formula  for  this 
separation,  based  on  the  assumptions  of  constant  final  approach  speed 
and  constant  takeoff  acceleration,  is  derived  in  Appendix  F.)  A 
takeoff  ties  up  the  end  of  the  runway  for  a separation  time  required 
between  takeoffs.  Points  on  other  runways  with  which  the  present 
runway  interferes  are  tied  up  in  a similar  manner.  For  intersecting 
runways , the  runway  threshold  and  the  end  of  the  runway  are  lied  up  until 
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a landing  or  a takeoff  passes  the  intersection  point  or  turns  off 
the  runway,  (The  formula  for  the  time  until  a landing  or  a 
takeoff  reaches  any  point  down  the  runway  is  derived  in  Appendix  G.) 

This  concludes  the  progress  of  our  hypothetical  flight,  except 
for  a final  routine  which  records  the  associated  delay.  This  delay 
is  recorded  at  touchdown  for  a landing,  and  at  the  start  of  roll  for 
a takeoff.  Therefore  the  delay  attributed  to  any  hour  only  refers  to 
delay  suffered  by  an  aircraft  which  touched  down  or  started  its  roll  in 
that  hour.  The  delay  itself  may  have  occurred  in  the  previous  hour,  or 
possibly  partially  even  before  that. 

To  summarize,  our  hypothetical  flight  has  gone  through  six  steps: 

1.  generate  flight; 

2.  file  flight  in  the  appropriate  queue; 

3.  find  the  next  flight  for  any  runway; 

4.  find  the  first  time  this  flight  can  use  its  runway  and 
(for  landings)  its  final  approach  path,  without  violating 
separation  rules; 

5.  tie  up  the  appropriate  points  to  maintain  separation  following 
this  flight;  and 

6.  record  flight  delay. 

2.2.5  Outputs 

The  final  portion  of  this  section  will  be  devoted  to  describing 
the  outputs  available  from  the  present  version  of  DELCAP.  We  will 
describe  later,  in  Chapter  5,  the  kinds  of  output  which  could  be  readily 


-32- 


provided  with  minor  changes  in  the  program;  it  is  sufficient  to  note 
here  that  the  current  set  of  outputs  is  only  representative  of  the 
potential  outputs  available  from  the  present  version  of  DELCAP. 

Toward  the  end  of  this  current  work,  a proposed  set  of  ’’mock  instructions" 
describing  the  DELCAP  model  was  circulated  within  the  FAA.  This  docu- 
ment was  designed  to  elicit  comments  on  the  model’s  usefulness  and 
descriptions  of  specific  problem  scenarios  in  which  it  could  be  applied. 

It  was  hoped  that  answers  to  the  questionnaire  accompanying  the  "mock 
instructions”  would  provide  a better  description  of  desired  model 
output.  However  this  particular  goal  of  the  circulation  was  not 
achieved,  and  so  the  present  model  output  remains  only  illustrative 
of  potential  outputs.  (The  "mock  instructions"  are  repeated  as 
Appendix  H.) 

Figure  2.2.1  shows  a typical  example  of  model  output.  Chapter 
4 will  include  a more  complete  description  of  model  runs;  we  are 
here  mainly  concerned  with  the  form  of  the  output.  The  section 
which  follows  this  will  describe  the  preprocessor  and  the  output 
from  it,  which  provides  labeling  for  a run  by  describing  that  run's 
input  specification.  The  output  in  Figure  2.2.1  however,  is  from 
the  simulation  model  portion  only. 
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The  airport  configuration  for  this  run  is  that  of  the  Atlanta 
airport  (ATL) . Delay  and  throughput  figures  were  accumulated  for 
24  hours,  starting  and  ending  at  8 a.m.-^  The  simulation  was  actually 
run  for  25  hours,  starting  at  7 a.m.  rather  than  8 a.m.  to  allow 
preloading  the  system  so  that  the  delay  and  throughput  calculations 
could  start  off  with  some  traffic  already  present.  The  starting 
hour  of  7 a.m.  was  chosen  because  there  is  very  little  traffic  at  this 
time  and  one  hour’s  preload  seems  to  be  sufficient. 


5/  The  column  labeled  HOUR  refers  to  the  hour  of  the  day,  so  that 
hour  1 is  from  midnight  to  1 a.m. , hour  8 is  from  7 to  8 a.m. , 
and  hour  17  is  from  4 to  5 p.m.  The  first  hour  for  which  delay 
was  recorded  is  therefore  actually  hour  9. 
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This  extra  hour  of  simulation  also  accounts  for  the  fact  that  one 
more  takeoff  was  performed  than  was  generated.  Even  without  delay,  the 
time  between  generation  and  takeoff  or  landing  is  15  - 20  minutes. 
Therefore,  those  aircraft  landing  or  taking  off  during  the  first  part 
of  hour  9 (8  am  to  9 am)  are  actually  generated  during  the  previous  hour, 
but  are  not  recorded.  Similarly,  toward  the  end  of  the  simulation 
aircraft  are  generated  which  land  or  take  off  only  after  the  simulation 
has  finished.  Therefore,  there  is  no  a priori  reason  for  the  recorded 
number  of  operations  generated  to  coincide  with  the  number  performed. 

The  distributions  of  landings  and  takeoffs  were  taken  from  data 
pertaining  to  San  Antonio  International  Airport.  However  about 
60  percent  of  San  Antonio  traffic  is  VFR,  whereas  in  our  present 
DELCAP  model  all  this  traffic  is  required  to  obey  IFR  rules.  This 
explains  the  high  level  of  simulated  delay,  which  would  certainly 
be  intolerable  at  a real  airport.  This  run  and  the  others  described 
in  this  report  should  be  interpreted  as  examples  of  possible  model  runs, 
rather  than  runs  based  on  actual  data.  (Within  the  time  and  resource 
limits  of  the  current  effort,  no  search  for  or  assimilation  of  data 
sources  was  possible.)  The  run  does,  however,  illustrate  the  capability 
of  the  DELCAP  model  to  portray  peaking  of  landings  and  takeoffs  and  the 
resultant  delays. 

It  should  be  remembered  when  examining  these  program  outputs 
that  the  delay  recorded  here  includes  only  that  encountered  in.  the  teiminal 
area  of  this  particular  airport,  between  handoff  to  tower  approach  control 
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and  landing  , or  between  desired  departure  time  and  handoff  to  center 
control  for  a takeoff.  "Delay"  refers  only  to  the  extra  time  above 
the  minimum  required  if  no  other  traffic  interfered.  Airlines  expect 
delays  at  certain  airports,  and  adjust  their  scheduled  arrival  times 
to  reflect  this.  The  model  does  not  include  the  expected  time  of 
arrival  for  any  flight.  Rather  it  computes  the  minimum  time  for  the 
flight  to  fly  from  handoff  and  land,  or  to  taxi  to  the  runway  and  take 
off.  Delay  is  then  calculated  as  the  difference  between  actual  time 
and  the  time  in  this  ideal  scenario. 

This  concludes  our  sketch  of  model  output  format.  The  next  section 
will  describe  the  preprocessor.  EUring  the  actual  running  of  the  model, 
the  preprocessor  precedes  the  simulation  portion  of  DELCAP.  We  have 
here  described  the  simulation  first  since  its  input-data  requirements 
are  what  the  preprocessor  is  designed  to  satisfy. 
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2.3  Specific  Descyiptipn  of  Preprocessor 

Since  the  DELCAP  model  was  designed  primarily  for  use  by  planners 
and  analysts,  ease  of  input  was  a major  consideration  in  its  formulation. 
The  SUBSCRIPT  computer  simulation  language,  chosen  because  it  greatly 
facilitates  simulation-model  programming,  unfortunately  requires  input 
in  a rigid  and  awkward  format.  Therefore  a preprocessor  program  was 
written  to  aid  the  user  in  inputting  data  to  the  simulation. 

It  is  hoped  that  DELCAP  will  ultimately  operate  in  a time -sharing 
computer  environment  in  which  an  analyst  would  need  only  to  (1)  call 
up  the  separation  rules,  and  the  configuration  and  traffic  levels,  for 
the  terminal  area  of  interest  in  the  year  under  investigation,  (2)  make 
any  desired  alterations  to  these  called-up  "standard"  data,  and  (3) 
receive  his  delay  and  throughput  measures,  all  in  a relatively 
short  time.  The  user  should  have  to  learn  only  a bare  minimum  about 
working  with  the  computer  (perhaps  only  how  to  arrange  accounting 
procedures  and  associated  job  numbers  and  how  to  call  up  the  DELCAP 
program).  The  DELCAP  model  would  have,  on  file,  airport  configurations 
and  traffic  levels  (present  and  projected)  for  most  of  the  terminals 
in  the  country  for  the  current  and  desired  projection  years.  The  model 
would,  if  the  user  requested,  print  out  the  information  contained  in 
any  of  its  files.  The  user  could  modify  (temporarily)  any  or  all  of 
the  contents  of  any  file  for  any  particular  run.  Those  items  he  did 
not  wish  to  modify  would  automatically  be  retrieved  from  the  proper  file 
stored  in  the  computer,  and  used  without  change  in  his  run.  This 
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philosophy  of  input  by  exception  to  entries  in  a standard  file,  we 
believe  to  be  an  ijnportant  feature  which  would  make  a model  such  as 
DELCAP  much  easier  to  use  and  therefore  much  more  apt  to  be  used.— ^ 

The  present  form  of  the  DELCAP  model  has  not  yet  achieved  this 
level  of  development.  The  current  effort  was  aimed  primarily  at  formulating 
and  implementing  the  simulation  model  logic.  To  indicate  how  the  proposed 
final  form  of  DELCAP  would  operate,  and  also  to  aid  in  data  input  to 
the  current  stage  of  development,  a FORTRAN  preprocessing  program  was 
written.  The  DELCAP  modeling  system  thus  presently  consists  of  two 
parts,  the  preprocessor  and  the  simulation  model,  which  are  run 
in  succession.  On  the  UNIVAC  1108  these  two  programs  can  be  executed 
one  after  another  in  a single  run.  For  computer  systems  which  do  not 
allow  multiple  executes,  two  runs  would  be  necessary.  The  preprocessing 
program  accepts  card  and/or  tape  input  as  desired,  and  produces  both 
a printed  run  description  and  a tape  containing  a SUBSCRIPT  initialization 
deck Z/,  which  in  turn  provides  input  to  the  simulation  model.  The 
simulation  is  then  run  to  produce  the  delay  and  throughput  statistics 
for  that  particular  set  of  inputs. 

The  present  file  of  airport  descriptions  contains  "data"  for  only 
two  airports f JFK  and  ATL.  Even  these  are  only  approximate.  The  runway 
configurations  were  obtained  from  [20]  which  does  not  include  the  distances 
(outer  marker  to  end  of  runway,  and  end  of  runway  to  intersection) 
needed  by  DELCAP.  The  operational  procedures  (landings  only",  takeoffs 

^Tkis  was  suggested  to  us  by  the  FAA,  and  after  considering  it 
carefully,  we  enthusiastically  concur. 

— -^For  a further  description  of  the  SIMSCRIPT  initialization  deck 
see  SIMSCRIPT,  A Simulation  Programming  Language,  by  Markowitz, 

Hausner  and  Karr.  A sample  decx  for  the  DELCAP  simulation  appears 
in  Appendix  A.  2. 
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only,  dual-use  alternate  operations  or  dual-use  landings  take  precedence), 
and  the  distribution  of  runway  use,  could  only  partially  be  inferred 
from  this  text.  No  information  was  given  on  how  landings  and  takeoffs 
were  distributed  over  the  hours  of  the  day.  Therefore  much  of  the  ’’data” 
for  these  two  airports  have  been  invented  either  wholly  or  in  part.  The 
distribution  of  landings  and  takeoffs  over  the  day  for  both  ATL  and 
JFK  was  taken  from  another  source  [22  ] and  applies  to  a different 
airport  entirely.  The  computer  runs  described  later  and  the  existing 
data  file,  therefore,  remain  only  illustrative  of  model  capability. 

They  do  provide,  however, a demonstration  of  how  the  model  would 
operate  as  an  aid  in  planning  and  analysis . 

As  mentioned  earlier  in  section  2.1,  the  preprocessor  divides 
model  input  into  six  data  groups.  The  user  may  specify  any  or  all  of 
these  groups.  The  particular  division  employed  is  somewhat  arbitrary 
and  may  be  altered  if  experience  running  the  program  suggests  a better 
arrangement.  The.  number  of  data  groups  could  also  be  changed,  but 
there  is  a tradeoff  between  the  flexibility  of  a larger  number  of 
data  groups  and  the  minimum  amount  a user  must  specify.  The  six  groups 
are: 

1.  description  of  aircraft  types, 

2.  mix  of  aircraft  types, 

3.  landing  and  takeoff  rates  by  hour  of  day, 

4.  separation  rules, 

5.  airport  configuration  and 

6.  fraction  of  each  type  of  aircraft  using  each  runway  and  departure 
path. 
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Input  for  data  groups  1 and  4 does  not  depend  on  the  airport,  and 
so  there  is  only  one  set  of  standard  values  for  these  groups.  The 
’’standard”  separation  rules  are  taken  as: 

a.  3 mile  interlanding  separation, 

b.  2 miles  separating  a landing  from  a preceding  takeoff  for 
aircraft  with  Distance  Measuring  Hquipment, 

c.  4 mile  departure/arrival  fix  for  aircraft  without  DME, 

d.  1 minute  separation  between  diverging  aircraft,  3 minutes 
between  aircraft  using  the  same  departure  path. 

The  standard  type  classification  is  that  given  in  the  Airport  Capacity 
Handbook,  pages  2.10  through  2.13.  Figure  2.3.1  records  the  standard  values 
of  variables  for  each  aircraft  type. 

The  remaining  four  data  groups  depend  on  the  airport  involved.  The 
user  may,  if  he  so  desires,  choose  different  groups  from  the  file  entries 
for  different  airports.  (The  identifier  appearing  on  the  preprocessor 
output  will  be  the  one  associated  with  airport  configuration-.)  Care 
should  be  taken  when  mixing  inputs  from  different  airports  that  they  all 
have  the  same  number  of  runways  and  departure  fixes.  In  describing 
the  airport  configuration  the  user  must  include  for  each  runway  a name 
consisting  of  a two- character  heading  (00  is  north,  13  is  130°  from 
north  or  roughly  southwest,  etc.),  and  where  desired  a one-  or  two- 
character  modifier  (e.g.,  13L  and  13R  for  parallels,  13FL  for  a 
third  parallel  to  the  left  of  13L) . These  are  used  only  for  identifying 
runways  in  the  preprocessor  output  and  are  not  needed  by  the  simulation. 
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SPEEDS  (KNOTS) 


TYPE 

A 

B 

C 

D 

E 


LANDING 

145 

140 

130 

115 

98 


LIFTOFF 

155 

148 

140 

123 

110 


RUNWAY  OCCUPANCY 
(SECONDS) 

LANDING  i TAKEOFF 


50 

44 

39 

33 

29 


33 

30 

28 

23 

21 


HAS 

DME? 

YES 

YES 

YES 

NO 

NO 


Figure  2.3.1:  Standard  Characteristics  of  Aircraft  Types 
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In  describing  the  runway  configuration  the  user  must  specify  two 
kinds  of  data:  (1)  for  each  pair  of  intersecting  runways, the  distance 

from  the  end  of  each  of  the  runways  to  the  intersection  with  the  other, 
and  (2)  for  each  pair  of  runways,  the  type  of  interference  between  them. 
There  are  two  types  of  interference.  In  the  first  type  the  two  run- 
ways are  completely  dependent,  i.e.  landings  and  takeoffs  on  one  runway 
must  be  separated  by  the  same  distances  from  those  on  the  other  as  from 
those  on  the  same  runway.  The  second  type  of  interference  requires 
successive  landings  on  each  one  of  the  pair  of  runways  to  be  separated 
by  the  same  distance  as  landings  on  a single  runway,  but  landings  on 
one  runway  do  not  affect  takeoffs  on  the  other,  and  simultaneous  takeoffs 
are  allowed  from  the  two  runways  if  the  takeoffs  diverge.  If  the  user 
does  not  specify  one  of  these  types  of  interference,  the  model  assumes 
that  operations  on  the  two  runways  do  not  affect  one  another. 

Figure  2.3.2  and  2.3.3  present  sample  output  from  the  preprocessor. 
They  describe  the  input  for  the  simulation  run  whose  output  was  given  in 
Figure  2.2.1.  Figure  2.3.2  gives  (a)  the  hours  for  which  the  simulation 
was  run  (in  this  case,  the  24  hours  from  8 a.m.  one  day  to  8 a.m.  the 
next),  (b)  the  characteristics  of  each  aircraft  type,  and  (c)  the  mix 
of  aircraft  types.  Figure  2.3.3  gives  a verbal  description  of  the  airport 
(in  this  case  our  hypothetical  ATL) . The  airport  description  includes 
the  operational  procedure  for  each  runway  and  the  interference  patterns 
among  the  runways.  Future  DELCAP  refinement  might  include  graphical 
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(schematic,  map-like)  output  of  the  airport  runway  configuration. 

Note,  however,  that  the  information  now  required  of  the  user  is  not 
always  sufficient  to  locate  all  runways  in  relation  to  each  other. 

If  two  runways  are  independent,  the  only  information  available  is 

the  heading  specification.  Since  the  user  is  not  repaired  to  specify 

the  runway  endpoint  and  length,  there  is  no  information  available 

in  the  current  data  set  indicating  that  the  two  parallels  91.  and 

9R  for  ATL  are  offset  parallels.  Tn  order  to  have  graphical  output, 

then  the  user  would  have  to  enter  extra  information  about  the  airnort 

(e.g.  , describing  the  runway  endpoint  in  some  x-y  grid)  which  is  not 

needed  by  the  simulation  program  and  whose  provision  would  reouire 

extra  work.  This  runs  counter  to  the  motivation  for  the  preprocessor , 

namely  to  allow  the  user  to  provide  input  in  an  easily  prepared  form 

requiring  a minimum  of  data  collection  and  preparation.  It  was 

therefore  decided  that  the  present  verbal  airport  description  is  adequate 

for  the  current  effort  and  may  even  be  preferable  to  a pictorial  description. 

xIany  variations  in  the  preprocessor  output  are  possible.  Qince 
the  DELCAP  model  has  not  yet  been  applied  to  a real-world  problem, 
it  is  impossible  at  this  stage  to  anticipate  which  of  the  possible 
outputs  would  be  most  useful  and  in  what  form  they  should  appear.  The 
output  of  the  preprocessor  is  designed  primarily  to  label  a run,  describing 
those  elements  which  differentiate  that  run  from  others.  Therefore, 
which  of  the  inputs  should  be  printed  out,  and  how  best  to  display  them 
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to  make  the  differences  between  two  runs  most  obvious,  depends  on  the 
particular  application.  The  present  form,  to  be  regarded  primarily 
as  an  example,  has  proved  useful  for  the  debugging  and  testing  runs 
of  the  current  effort. 
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Figure  2.3.3:  Sample  Preprocessor  Output 
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This  concludes  our  functional  description  of  the  preprocessor 
and  simulation.  The  next  chapter  will  provide  a more  technically  oriented 
description,  tied  more  closely  to  the  implementation  of  the  model  as  a 
computer  program.  The  reader  less  concerned  with  such  matters  may 

wish  to  skip  to  Chapter  4,  which  describes  the  outputs  from  illustrative 
runs  of  the  model. 
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3.  DESCRIPTION  OF  COMPUTER  IMPLEMENTATION 


3.1  General  Remarks 

The  previous  chapter  described  the  model  from  the  viewpoint  of  a 
reader  familiar  with  terminal-area  operations,  but  not  necessarily  with 
computer  modeling.  In  this  chapter,  we  present  the  model  from  the  latter 
point  of  view. 

Since  the  computer  simulation  model  was  written  in  SIMSCRIPT,  we 
will  often  find  it  convenient  to  describe  the  model  using  the  terminology 
of  that  language.  The  reader  may  thus  desire  to  refer  to  SIMSCRIPT  ,A  Simu- 
lation Programming  Language,  by  Markowitz,  Hausner,  and  Karr  for  a more 
complete  account  of  these  terms.  A partial  glossary  of  terms  which  will 
be  used  frequently  follows: 

event  - The  simulation  program  consists  of  a series 
of  subprograms  (called  event  routines) 
describing  the  change  in  the  status  of  the  systent 
at  each  critical  event.  There  are  two  types  of 
events:  exogenous  events,  which  happen  at  specific 

times  input  to  the  simulation,  and  endogenous  events, 
which  occur  as  a consequence  of  sane  preceding 
event  in  the  simulation. 


~ System  here  refers  to  that  which  is  being  modeled,  the  terminal  area. 
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function  - In  addition  to  event  subprograms  SIMSCRIPT 


entities  - 


attribute 


set  - 


includes  "function"  routines  which  are 
similar  to  FORTRAN  FUNCTION  -programs  in  that 
they  calculate  a value  of  a function  for 
a given  set  of  values  of  certain  parameters. 
Entities  are  the  objects  which  the  simulation 
models.  There  are  two  types:  temporary 

entities,  which  during  the  course  of  a siitiu- 

\ 

lation  come  into  the  system  and  later  leave 
(e.g.,  flights),  ahd  permanent  entities 
whose  number  remains-  fixed  during  any  simu- 
lation run  (e.g.,  runways  and  aircraft 

tynes) . 

- Attributes  are  properties  associated  with 
temporary  entities  and  events.  They  provide 
additional  information  about  the  specific 
event  or  entity,  such  as  the  type  of  a given 
flight  or  the  identity  of  the  runway  upon 
which  a given  landing  is  to  occur. 

Sets  are  lists  of  particular  entities.  When 
an  entity  is  added  to  the  list  it  is  said 
t°  be  filed  in  the  set.  Sets  may  be  ordered 
in  any  of  several  ways.  A FIFO  set  is  ordered 
in  a first -in- first -out  manner  (e.g.,  the  landing 


-50- 


and  takeoff  queues)  . The  opposite  is  a LIFO  set, 
last- in  first-out.  Finally,  sets  may  be 
ranked  on  some  attribute.  An  example  of 
of  this  in  the  simulation  is  the  set  of 
tieups  associated  with  any  of  a runway’s 
three  interference  points.  These  sets 
are  ranked  on  the  time  at  which  the  tieup 
is  no  longer  in  force. 

schedule  - When  using  the  SIMSCRIPT  language,  the 

programmer  need  only  write  code  for  each  of 
the  critical  events.  Endogenous  events 
(which  occur  as  the  result  of  other  events) 
must  be  scheduled  within  the  caus ing-cvcnt 
routine.  These  scheduled  events  are  then  put 
in  a list  of  future  events;  after  finishing 
each  event,  the  SIMSCRIPT  system  checks  to 
find  the  next  event  in  this  list. 

create  and  destroy  - When  temporary  entities  enter 

the  system  they  are  said  to  be  created,  and 
when  they  leave  they  are  said  to  be  destroyed. 

In  the  computer,  when  an  entity  is  created 
storage  is  reserved  for  it,  and  when  it  is 
destroyed  this  storage  is  returned  to  the 
SIMSCRIPT  program  and  can  be  reassigned. 
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The  DELCAP  model  is  currently  operable  under  the  EXEC  II 
operating  system  on  the  UNIVAC  1108  at  the  National  Bureau  of  Standards. 
The  preprocessor  is  written  in  FORTRAN  V (UNIVAC's  augmented  FORTRAN  IV), 
and  the  simulation  in  SIMSCRIPT  ] .5.  A minimum  of  difficulty  is 
anticipated  in  converting  the  program  to  other  computers,  since 
care  has  been  taken  to  design  the  program  to  be  compatible  with  other 
computer  systems.  However,  to  aid  in  the  conversion  process  we  have 
included  in  Appendix  E a list  of  possible  areas  of  computer  incompati- 
bility which  have  arisen  in  other  efforts  in  which  members  of  this 
project  staff  have  participated.  SIMSCRIPT  1.5  is  available  on  a wide 
range  of  computers,  and  most  of  the  compilers  were  written  by  a single 
company,  increasing  the  likelihood  of  easy  transference. 

The  present  preprocessor  consists  of  about  500  FORTRAN  statements, 
including  comment  cards  as  necessary.  A listing  of  the  program  appears 
in  Appendix  C.  The  example  preprocessor  run  described  in  the  previous 
chapter  took  about  3 seconds  to  execute.  This  running  time  will  be 
increased,  however,  when  the  file  of  standard  airport  data  becomes 
large,  since  much  of  the  execution  time  would  then  be  spent  in  searching 
for  the  correct  airport  information.  The  preprocessor  uses  about 
6600  words  of  core  storage • The  current  limits  on  the  number  of 
runways,  aircraft  types  and  departure  paths  depend  more  on  some  of 
the  formats  in  the  preprocessor  than  on  actual  core  limits.  These 
limits  are:  9 runways,  10  types,  and  5 departure  paths.  The  maximum 
total  number  of  interferences  allowed  is  10.  These  values  are  parametrized 
in  the  preprocessor,  and  may  be  changed  along  with  necessary  formats 
if  these  limits  need  to  be  increased.  It  should  be  noted  here  that 


-52- 


the  term  "runway"  refers  to  a runway  operating  in  a particular  direction. 
(13  and  31  are  two  separate  runways.)  Since  the  runways  are  fixed 
for  a particular  run,  and  runways  are  not  usually  operated  in  both 
directions  at  once,  this  does  not  present  too  great  a problem. 

However,  the:re  could  be  a problem  in  the  future  when  the  tape  of 
standard  airport  data  is  created,  since  there  would  then  be 
several  different  runway  configurations  for  each  airport  which  must 
be  distinguished,  (e.g.,  for  Washington  National,  DCA  north  operations 
vs.  DCA  south  operations). 

The  simulation  model  consists  of  about  1300  SIMSCRIPT  statements 
including  comment  cards.  A listing  appears  in  Appendix  D.  The 
example  runs  took  about  9 to  10  seconds  to  simulate  25  hours.  (The 
simulation  was  run  for  1 hour  to  preload  the  system  and  then  for 
24  hours  to  accumulate  output  statistics.)  This  time  is  exclusive 
of  compilation,  which  takes  about  1.5  minutes.  Of  course,  once  the 
DELCAP  model  system  is  in  the  production  phase,  compilation  would 
no  longer  be  necessary. 

On  the  1108,  SIMSCRIPT  compilation  is  a two- stage  process.  First 
the  SIMSCRIPT  object  code  is  compiled  into  SLEUTH,  the  1108  assembly 
language;  then  the  SLEUTH  is  assembled.  Storage  has  never  become  a 
problem  with  the  simulation  program.  Even  with  20  runways,  200  types 
of  aircraft  and  40  departure  paths,  the  data  storage  requirements  are 
less  than  20,000  words.  For  an  airport  with  20  runways  there  could  be 
a maximum  of  about  5,000  additional  storage  locations  used  to  store 
information  concerning  temporary  entities  and  events.  These  estimates 
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are  all  very  conservative.  (No  existing  airport  has  20  runways, 
for  instance.)  Thus  it  is  not  anticipated  that  computer  storage 
requirements  will  limit  the  applicability  of  the  present  version  of 
the  DELCAP  model. 

The  minimum  number  of  data  cards  required  for  a run  of  DELCAP 
is  three,  two  for  the  preprocessor  and  one  for  the  simulation. 

The  user  must  supply  at  least  the  first  and  last  hour  for  the 

simulation,  and  also  the  preprocessor  parameter  card  indicating  which  of 
the  data  groups  should  be  standard  data  and  for  which  airports.  The 
simulation  requires  a SIMSCRIPT  system  specification  cardi/ which  will 
be  described  in  greater  detail  in  Section  3 of  this  chapter. 

This  concludes  our  general  remarks  on  the  computer  implementation 
of  the  DELCAP  model.  The  following  two  sections  will  describe  the 
preprocessor  and  simulation  programs  respectively. 


'bee  pages  101  and  102  of  SIMSCRIPT,  A Simulation  Programming 
Language  for  a further  description  of  this  card. 
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3.2  The  Preprocessing  Program 


The  preprocessor  was  designed  to  aid  the  user  in  providing  input 
to  the  DELCAP  model.  It  has  two  major  functions.  First,  it  accepts  user  - 
supplied  input  in  a relatively  easily -prepared  format,  and  outputs  these 

data  in  the  more  cumbersome  foimat  required  by  the  simulation.  Second, 
it  provides  ’’standard”  values  for  those  input  items  which  the  user  does 
not  wish  to  specify  . In  addition,  it  checks  the  input  for  consistency 
and  prints  warning  messages  as  necessary.  Figure  3.2.1  is  a flowchart 
of  the  preprocessor  program.  Although  the  middle  section  appears  as  a 
loop,  the  six  data  groups  differ  enough  in  structure  as  to  require 
six  separate  portions  in  the  program.  As  is  seen  from  the  figure, 
the  program  can  be  broken  into  four  sections: 

1.  Read  the  hours  to  be  simulated  and  the  options  card. 

2.  Compile  the  data  for  the  six  data  groups,  from  user- 
supplied  input  or  standard  files  as  directed. 

3.  Write  a tape  providing  simulation  input. 

4.  Print  the  run  identifications. 

The  program  always  requires  at  least  two  input  cards.  The  first 
of  these  specifies  the  beginning  and  ending  times  for  the  simulation. 

Time  is  expressed  in  military  time,  e.g.,  0.00  stands  for  midnight, 

8.30  for  8:30  a.m.  and  17.20  for  5:20  p.m.  The  program  will  not  at 
present  accept  a run  of  over  24  hours.  (Note;  a ”24  hour  run”  is  one 
which  simulates  25  hours  but  records  delay  only  for  the  final  24.)  A 
run  from  8.00  to  8.00  is  interpreted  as  a 24  hour  run  from  8 a.m.  one 
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Figure  3.2.1:  Preprocessor  Flowchart 
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day  to  8 a.m.  the  next.  Thus  the  input  to  the  simulation  reads  from 
hour  8 to  hour  32  in  this  case.  The  simulation  is  always  run  for  at 
least  one  full  hour  (and  up  to  two) , to  preload  the  system  before  beginning 
to  record  delay  and  throughput.  If  the  simulation  is  to  start  on  the  hour, 
it  will  be  started  exactly  one  hour  early.  If  the  simulation  is  to  start 
at  5:45,  it  will  be  run  for  an  initial  hour  and  45  minutes.  The  maximum 
preload  time,  then, is  one  hour  and  59  minutes.  The  simulation  always 
begins  its  preloading  at  the  hour,  but  it  will  end  at  whatever  minute  the 
user  has  specified. 

The  second  data  card  required  by  all  runs  of  the  preprocessor 
specifies  which  of  the  six  data  groups  will  use  standard  input.  Even 
if  the  user  wants  to  specify  values  for  all  six  groups,  this  data  card 
(in  this  case,  blank)  must  appear  in  the  deck.  ' For  data  groups  1 and  4 
which  are  not  airport -specific,  any  non-blank  character  will  indicate 
standard  input.  For  the  remaining  data  groups,  the  user  who  desires  to 
use  standard  input  must  specify  the  airport  in  the  airport  file  for 
which  he  wishes  to  extract  the  data.  Airports  are  referred  to  by  their 
3- character  code  names  (JFK  for  New  York’s  John  F.  Kennedy  International 
Airport,  for  instance) . If  the  particular  airport  desired  is  not  in  the 
file,  the  preprocessor  will  print  a warning  message  and  discontinue 
processing.  The  user  may  request  data  for  different  data  groups  to  be 
drawn  from  different  airports.  However,  he  should  ensure  that  the 
different  airports  have  compatible  sets  of  data:  the  numbers  of  runways 

and  departure  fixes  must  be  the  same.  Also,  if  the  user  provides  a 
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non-standard  aircraft  type  description,  he  should  realize  that  standard 
airport  data  which  depend  on  aircraft  type  (such  as  the  time  to  fly 
from  handoff  to  the  outer  marker)  have  values  referring  to  the  standard 
5 types  of  aircraft.  The  general  point  to  be  borne  in  mind  is  that  the 
six  data  groups  are  not  fully  independent,  so  that  care  must  be  taken  to 
avoid  inconsistencies  between  groups. 

The  next  subsections  of  this  section  will  describe  in  greater  detail 
the  data  contained  in  each  of  the  six  data  groups.  The  formats  for  the 
input,  and  sample  input  decks,  are  given  in  Appendix  A.  The  listing  of 
the  preprocessor  code  appears  in  Appendix  C. 

3.2.1  Data  Group  1 - Aircraft  Type  Description 

This  data  group  provides  the  values  of  variables  which  characterize 
the  aircraft  types  involved  in  a particular  Simulation.  The  standard 
input  values  were  given  in  the  previous  chapter  (figure  2.3.1).  The  5 
standard  types  of  aircraft  are  described  in  detail  in  the  Airport  Capacity 
Handbook  (pp.  2.10  to  2.13),  and  depend  mainly  upon  weight  and  means  of 
propulsion.  These  types  may  be  categorized  roughly  as  follows: 

(1)  type  A - large  jets 

(2)  type  B - medium  jets  and  large  propeller 

(3)  type  C - small  jets  and  medium  propeller 

(4)  type  D - light  twin  engine 

(5)  type  E - single  engine 

If  the  user  elects  to  provide  his  own  aircraft  type  data,  he  must 
stipulate  landing  and  liftoff  speeds  (in  knots) , runway  occupancy  times 
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on  landing  and  also  on  takeoff  (in  seconds) , and  possession  or 
non-possession  of  DME  for  each  type  of  aircraft.  The  number 
of  types  is  flexible,  but  the  current  preprocessor  program 
limit  is  10.  This  limit  is  parametrized  and  may  easily  be  increased 
with  a single  program  change.  Note  that  data  groups  2,  5,  and  6 all  refer 
to  information  which  pertains  to  aircraft  type.  The  number  of  types  of 
aircraft  and  the  basic  type  information  are  provided  by  data  group  1, 
with  which  the  information  contained  in  the  other  groups  must  conform. 

This  is  the  responsibility  of  the  user;  the  present  program  does  not 
perform  such  consistency  checks. 

The  unit  of  time  used  in  the  simulation  is  the  hour.  Therefore  the 
runway  occupancy  times  (given  in  seconds)  are  immediately  changed 
to  hours  by  dividing  by  3600. 

An  additional  variable  must  also  be  provided  by  the  user  electing  to 
use  non-standard  aircraft-type  input:  the  speed  (in  knots)  at  which  a 
landing  turns  off  the  runway.  This  is  used  in  the  simulation  when 
calculating  the  time  at  which  an  aircraft  reaches  an  intersection  of 
runways.  From  touchdown  until  turnoff,  an  aircraft  is  assumed  to  be 
constantly  decelerating  from  landing  speed  to  turnoff  speed.  The 
calculation  of  the  time  to  reach  any  point  down  the  runway , under  this 

assumption,  is  given  in  Appendix  G. 
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3.2.2  Data  Group  2 - Mix  of  Aircraft  Types 

The  second  data  group  which  the  user  may  specify,  if  he  so  desires, 
is  the  mix  of  aircraft  types.  For  each  type  of  aircraft,  he  must  give 
the  fraction  of  the  landings  which  are  of  that  type  and  also  the  fraction 
of  takeoffs.  The  fractions  for  landings  must  add  to  one,  and  similarly  for 
takeoffs.  If  one  or  both  does  not,  an  error  message  will  be  printed,  but 
processing  will  continue  . Since  the  simulation  model  will  need  the  cumu- 
lative distributions,  the  fractions  are  immediately  converted  to  those 
distrubutions  in  the  preprocessing  program.  If  the  user  elects  to  accept 
standard  data,  he  must  specify  the  airport  whose  mix  he  wishes  to  use. 

The  standard  mixes  all  refer  to  the  standard  five  types. 

3.2.3  Data  Group  3 - Landing  and  Takeoff  Rates,  by  Hour  of  Day 

This  data  group  provides  the  distribution  over  time  of  aircraft 

entering  the  system.  There  are  two  distributions,  one  for  landings  and  one 
for  takeoffs,  since  the  time-of-day  patterns  may  be  different  for  the  two. 
The  user  who  wishes  to  provide  non-standard  data  must  input  the  desired  num- 
ber of  landings  and  a number  of  takeoffs  for  each  simulated  hour,  up  to  a 
maximum  of  24  hours.  The  preprocessor  is  presently  set  up  to  handle 
up  to  a day’s  worth  of  data.  The  simulation  can  be  run  for  more  than 
24  hours,  but  the  landing  and  takeoff  rates  will  then  repeat  in  a 24 
hour  cycle.  If  the  simulation  is  to  be  run  for  less  than  24  hours,  the 
user  must  remember  that  the  system  is  preloaded  for  between  one  and  two 
hours  before  it  actually  starts  recording  delay  and  throughput  (recall 
section  3.2.1).  The  user  must  provide  landing  and  takeoff  rates  for  the 
preload  time  period  as  well  as  the  period  for  which  delay  and  throughput 
are  to  be  recorded.  The  simulation  needs  the  average  time  between 
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landings  or  takeoffs  rather  than  the  number  of  them  per  hour  and  so 
the  preprocessor  estimates  the  mean  time  between  landings  or  takeoffs  as 
the  reciprocal  of  the  number  per  hour.  If  there  are  no  landings  Cor 
no  takeoffs)  in  an  hour,  the  time  between  landings  is  set  at  9.999  hours, 
so  there  is  a finite  but  very  small  probability  of  generating  a landing. 

The  user  must  specify  the  airport  from  which  the  landing  and  takeoff  rates 
are  to  come.  The  input  data  tape  will  be  searched  for  this  infoimation 
if  this  airport  is  not  the  same  as  the  one  specified  for  data  group  2,  or 

if  data  group  2 was  user-specified. 

3.2.4  Data  Group  4 - Separation  Requirements 

This  data  group  provides  numerical  values  for  the  separation  rules 
which  are  to  apply  to  a simulation  run.  There  are  three  types  of  separation 
rules:  (1)  interlanding,  (2)  landing  following  takeoff,  and  (3)  inter- 

takeoff. The  fourth  possibility,  a takeoff  following  a landing,  is 
governed  by  the  ”no  two  aircraft  on  the  same  runway  at  the  same  time" 
rule.  The  takeoff  may  taxi  onto  the  runway  and  start  its  roll  as  soon 
as  (but  not  before)  the  preceding  landing  has  turned  off  the  runway.  The 
presently  required  interlanding  separation  is  3 miles.,/  In  general,  all 
landings  must  maintain  this  separation,  unless  the  two  aircraft  are  to  land 
on  parallel  runways  separated  by  at  least  5,000  feet. 

The  rules  defining  the  separation  between  departing  aircraft  are 
much  more  complicated,  and  depend  on  the  paths  the  departure  will  take. 
These  rules  for  IFR  aircraft  are  given  on  pages  96  and  97  of  Teimnal  Air 

Traffic  Control. 

-^lll  separation  rules  are  expressed  in  nautical  miles . 
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The  rules  are  approximated  within  the  simulation  by  the  following 
scheme:  Each  takeoff  is  assigned  a departure  path  when  it  is  generated. 

The  simulation  uses  two  arrays  which  determine  the  required  separation 
between  aircraft,  one  for  departures  on  the  same  runway  and  one  for  those 
on  different  runways.  These  arrays  contain  for  each  pair  of  departure 
paths,  a time  separation  between  start  of  roll  for  aircraft  outbound 
on  those  two  paths.  Our  present  procedure  (just  described)  is  only  an 
approximation  to  the  rules  cited  above  in  that  (a)  the  separation  is 
not  made  to  depend  on  aircraft  type,  and  (b)  the  separation  requirement 
is  not  extended  into  the  airspace  beyond  the  airport.  [In  addition,  one 
of  the  present  separation  rules  is  in  terms  of  distance  rather  than  time. 
The  user  may  approximate  this  by  calculating  a weighted  (by  the  mix 
of  aircraft  type)  average  of  the  time  for  an  aircraft  to  fly  the  required 
separation  distance  (3  miles).] 

The  standard  values  for  these  arrays  are:  1 minute  for  aircraft 

flying  different  paths  and  3 minutes  for  those  flying  the  same  path,  for 
takeoffs  from  the  same  runway;  and  2 minutes  for  aircraft  taking  off  from 
different  runways  but  then  following  the  same  departure  path.  No 
separation  rule  is  imposed  on  aircraft  departing  on  different  runways 
for  different  departure  paths.  (The  representation  scheme  for  aiiport 
configurations  to  be  described  in  section  3.2.5  below  will  include  a 
method  of  indicating  to  which  pairs  of  runways  the  inter- takeoff 
separation  must  apply.) 
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The  final  type  of  separation  is  that  required  between  a takeoff  and 
a following  landing.  The  separation  depends  on  whether  or  not  the  land- 
ing possesses  EME.  If  a landing  does  possess  DME  then  it  must  remain  a 
required  separation  distance  (presently  2 miles)  behind  the  takeoff.  If 
the  aircraft  does  not  have  DME,  however,  it  must  not  pass  a certain 
fix  (called  the  departure/ arrival  fix)  before  the  takeoff  starts  its  roll. 
In  our  program,  the  standard  value  for  the  departure/ arrival  fix  is  4 
miles  from  the  end  of  the  runway. 

3.2.5  Data  Group  5 - Airport  Description 

This  data  group  describes  the  airport’s  runway  configuration  and 
operating  policies.  The  user  who  wishes  to  use  non-standard  data  must 
specify  for  each  runway  a two -character  heading  (00  is  north,  13  is 
130°  from  north  or  roughly  southwest,  etc.),  and  a two-character 
modification  if  desired.  The  latter  can  be  used  to  designate  the 
left  (L)  and  right  (R)  members  of  a pair  of  parallel  runways.  The 
four  characters  (heading  and  modification)  are  needed  only  by  the 
preprocessor,  and  are  used  to  label  the  runways  on  the  preprocessor 
output . 

The  user  must  also  provide  both  the  distance  (in  nautical  miles) 
from  the  runway  threshold  to  the  outer  marker  and  the  operation  code 
for  each  runway.  The  code  specifies  which  of  four  different  operating 
policies  governs  the  runway:  (1)  takeoffs  only,  (2)  landings  only, 

(3)  dual  use,  alternate  operations,  and  (4)  dual  use,  landings  take 
precedence.  The  user  may  pick  any  one  of  these  policies  for  any 
runway,  but  he  should  make  sure  that  the  policy  agrees  with  the  dis- 
tribution of  runway  use  in  data  group  6. 
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For  each  aircraft  type,  the  user  must  provide  the  minimum  time  (in 
minutes)  to  fly  from  handoff  to  the  outer  marker.  (The  preprocessor 
immediately  converts  the  time  units  to  hours,  the  time  unit  needed 
by  the  simulation.) 

In  describing  the  runway  configuration,  the  user  must  provide 
for  each  pair  of  intersecting  runways  the  distance  (in  feet)  from 
the  end  of  the  first  runway  to  the  far  side  of  its  intersection  with 
the  second,  and  the  distance  from  the  end  of  the  second  to  the  far 
side  of  its  intersection  with  the  first.  These  distances  are  immediately 
changed  to  their  equivalents  in  nautical  miles. 

The  model  does  not  need  to  have  the  actual  layout  of  the  airport, 
but  it  does  need  to  know  how  the  runways  can  interfere  with  one  another. 

The  user  may  specify  "interference  code  1"  which  means  that  landings  on 
the  two  runways  must  be  separated  by  the  same  distance  as  are  landings 
on  one  runway,  but  that  takeoffs  are  independent  of  landings  and  of  other 
takeoffs.  If  the  user  specifies  code  2,  then  landings  on  the  two 
runways  must  be  separated  by  the  same  distance  as  landings  on  one  runway, 
a landing  on  one  must  be  separated  from  a previous  departure  on  either 
runway,  and  takeoffs  on  the  two  runways  must  be  separated  by  the  special 
separations  required  of  takeoffs  on  dependent  runways.  If  the  user  does 
not  specify  a code  for  any  pair  of  runways,  it  is  assumed  that  operations 
on  the  one  do  not  affect  operations  on  the  other.  The  preprocessing  program 
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uses  this  information  to  create  the  arrays  which  are  used  by  the 
simulation  to  tie  up  appropriate  points  for  the  appropriate  lengths  of  time. 

3.2.6  Data  Group  6 - Runway  Use  and  Departure  Fix  Distributions 

The  user  who  wishes  to  provide  his  own  input  for  this  data  group  must 
supply,  for  each  type  of  aircraft,  the  fraction  which  uses  each  runway  for 
takeoffs  and  the  fraction  which  uses  each  runway  for  landing.  He  must  also 
specify  for  each  runway,  the  fraction  of  takeoffs  using  each  departure 
path.  The  program  checks  that  the  fractions  sum  to  one,  and  prints  an 
error  message  if  not.  In  addition,  it  checks  that  a runway  which  is  to 
be  operated  "takeoffs -only"  does  not  have  any  landings  using  it,  and 
that  a runway  being  operated  as  "landings -only"  does  not  have  any  takeoffs 
using  it.  Here  too  inconsistencies  lead  to  the  printing  of  error  messages. 
Processing  continues  in  spite  of  error  messages. 

The  preprocessor  next  computes  some  other  arrays  used  in  the  simulation 
model.  The  "latest  operation  on  each  runway"  is  initialized  as  a landing, 
unless  the  runway  handles  takeoffs  only.  The  minimum  time  a takeoff 
must  remain  in  its  queue  is  computed  as  a weighted  average  (weighted 
by  aircraft  type)  of  the  times  to  fly  from  handoff  to  the  outer  marker 
The  minimum  time  between  when  a takeoff  may  be  scheduled  and  when  it 
actually  starts  its  roll  is  computed  as  a weighted  average  (weighted  by 
aircraft  types)  of  the  time  for  a landing  to  fly  down  the  final 
approach  path  from  outer  marker  to  runway  threshold.  These  two  times 
can  be  interpreted  respectively  as  (a)  the  minimum  time  between  filing  a 
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flight  plan  and  leaving  the  gate,  and  (b)  the  minimum  taxiing  time  from 
the  gate  to  the  end  of  the  runway.  However,  as  can  be  seen  from  the  way 
they  are  computed,  their  primary  purpose  in  the  model  is  to  ensure  that 
takeoffs  are  scheduled  about  the  same  time  ahead  of  start  of  roll  as 
landings  are  ahead  of  touchdown.  A further  discussion  of  these  arrays 
is  given  in  the  next  section. 

3.2.7  Simulation  Input 

The  main  function  of  the  preprocessor  program  is  to  provide  an  input 
deck  for  the  simulation  model.  Every  SIMSCRIPT  program  requires  an 
"initialization  deck"  which  gives  the  number  of  each  of  the  permanent 
entities  and  initial  values  for  the  system  variables  and  arrays  for  the 
current  run.  The  DELCAP  model  has  five  permanent  entities;  two  of  these - 
the  number  of  types  of  operations  (2)  and  the  number  of  hours  in  a day  (24)- 
remain  constant  for  all  runs , while  the  other  three  - the  number  of  run- 
ways, the  number  of  types  of  aircraft,  and  the  number  of  departure  paths  - 
can  vary  from  run  to  run.  The  values  of  the  preprocessor  input  groups, 

whether  standard  or  user-specified,  are  written  out  in  the  format  re- 

4 / 

quired  by  SIMSCRIPT.—  The  arrays  which  store  the  simulation  output  delays 
and  throughputs  are  initialized  at  zero.  The  preprocessor  also  provides 
one  "exogenous  event"  card  image  on  the  simulation  input  tape.  This  card 
schedules  the  BEGIN  event  which  starts  the  simulation.  If  the  user  is 
providing  deteministic  flight  input,  then  he  must  also  provide  this  card 
image  as  the  first  exogenous  event. 

4/ 

-See  pages  115  to  128  of  SIMSCRIPT, A Simulation  Programming  Language 
and  Appendix  D. 
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3.2.8  Preprocessor  Output 

The  preprocessor  prints  out  information  to  label  a particular  run. 
The  current  print -out  is  not  complete,  but  has  provided  adequate 
labeling  for  the  debugging  runs  of  the  current  effort.  Future  running 
of  the  model  in  an  airport -planning  environment  should  yield  a better 
idea  of  which  data  items  would  constitute  the  best  labeling. 

Sample  preprocessor  output  appears  in  Figures  2.3.2  and  2.3.3,  to 
which  we  now  refer  again.  The  first  line  of  output  gives  the  hours 
the  simulation  will  be  run.  (Any  error  warning  messages  appear 
immediately  following  this  line.)  Next,  the  landing  and  liftoff  speeds 
and  runway  occupancy  times  are  given  for  each  aircraft  type.  The 
mix  of  aircraft  types  for  landing  and  for  takeoff  are  listed  next. 

At  the  end,  the  preprocessor  prints  a verbal  description  of  the  airport 
configuration,  including  the  appropriate  three -character  airport 
identifier.  Each  runway  is  listed  by  number  and  by  name  (e.g.,  9L) , 
and  the  type  of  operation  (takeoffs  only,  landings  only,  dual  use  with 
alternating  operations,  and  dual  use  with  landings  taking  precedence) 
is  printed.  Next,  intersections  are  listed.  Finally,  interferences 
are  listed.  Two  runways  with  the  same  heading  are  identified  as 
”parallel".  Parallels  may  be  independent,  semi -dependent  (landings  on 
one  interfere  with  landings  but  not  takeoffs  on  the  other) , or 
dependent  (landings  and  takeoffs  on  one  must  be  separated  from  landings 
and  takeoffs  on  the  other) . Only  semi -dependent  and  dependent  non- 
parallel runways  are  listed. 
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This  concludes  our  description  of  the  preprocessor  program.  We 
wish  to  reemphasize  that  the  particular  current  forms  of  the  input 
to  this  program,  and  of  the  printed  outputs,  were  dictated 
largely  by  our  needs  during  program  debugging.  Because  the  program 
has  not  yet  been  used  in  any  real  planning  situations,  some  of  its 
features  may  prove  awkward  for  users  less  familiar  with  the  computer. 

We  have  conscientiously  tried  to  foresee  such  difficulties  and  to 
eliminate  them  in  advance,  but  as  yet  the  program  is  still  in  the  prototype 
stage.  Only  its  exercise  in  more  of  a "production"  environment  can 
be  relied  on  to  reveal  fully  such  product ion -use  difficulties  as  may 
remain,  and  only  after  these  problems  are  revealed  can  they  be 
remedied. 
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3.3  The  Simulation  Program 


The  simulation  program  is  written  in  the  SIMSCRIPT  1.5  pro^ 
gramming  language,  which  is  designed  primarily  to  aid  in  programming 
critical-  erent  simulations.  The  user  only  needs  to  write  code  for 
each  of  the  types  of  events,  describing  how  each  alters  the  status 
of  the  system  being  modeled  and  how  other  events  depend  on  this  one. 

The  SIMSCRIPT  compiler  contains  several  programs  which  execute  the 
user-designed  evait  routines  in  chronological  order.  Storage  for 
temporary  entities,  and  for  events  which  have  been  scheduled  but 
not  yet  executed,  is  dynamically  allocated  by  other  SIMSCRIPT 
routines.  The  size  of  arrays  and  their  allocation  of  storage  are 
computed  at  execution  time,  when  sets  of  initial  values  are  read  for 
them.  The  simulation  is  started  off  by  an  exogenous  event,  in  our 
simulation  the  BEGIN  event  which  schedules  the  routine  to  generate 
the  first  landing  flight  and  first  takeoff  flight. 

Figure  3.3.1  gives  a general  ’’flowchart”  of  the  DELCAP  simu- 
lation model  routines.  Hie  word  ’’flowchart”  is  somewhat  of  a misnomer 
in  the  context  of  a SIMSCRIPT  model.  The  diagram  indicates  which 
event  routines  occur  as  a result  of  which  other  routines , but  it 
does  not  give  the  order  in  which  they  are  actually  executed,  since 
this  is  chronological.  (Recall  the  discussion  in  section  2.1.)  The 
earlier  Figure  2.1.1  gave  a flowchart  of  the  DELCAP  critical  events 
for  a single  aircraft.  Figure  3.3.1  describes  the  computer  implementation 
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Figure  3.3.1:  Flowchart  of  the  DELCAP  Simulation  Routines 
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of  this  process. 


Events  GEN  and  EXGEN  create  flights  , which  are  the  units  which 
move  through  the  various  events  in  the  model.  EXGEN  is  an  exogenous 

event  which  occurs  at  times  designated  for  the  arrival  into  the  system 
of  specific  flights.  GEN  creates  flights  in  a stochastic  manner. 
Stochastically  generated  flights  are  assigned  a type,  a runway,  and 
a departure  path  by  the  three  functions  PTYPE,  PRWAY,  and  PDFIX. 

Flights  are  constantly  entering  the  system  while  other  events  are 
happening.  GEN  schedules  the  next  occurrence  of  itself  according 
to  the  Poisson  process,  while  the  next  specific  flight  (if  any  are 
left)  for  EXGEN  is  always  available.  The  event  NXTOP  finds  the  next 
operation  (landing  or  takeoff)  which  is  to  occur  on  a particular  run- 
way.  It  is  scheduled  in  one  of  two  ways:  (1)  if  the  queue  is  empty 

when  the  current  flight  is  filed  in  it,  or  (2)  when  the  current  flight 
has  either  begun  to  fly  the  final  approach  path  to  land  or  has  left 
its  gate  to  take  off.  Condition  (1)  is  detected  in  GEN  or  EXGEN, 
and  condition  (2)  in  LAND  or  TOFF.  NXTOP  then  schedules  the  next 
LAND  or  TOFF  at  the  time  the  runway  and/or  final -approach  path  is 
free,  as  determined  by  the  function  FREER.  Since  there  is  a time  gap 
between  NXTOP  and  TOFF  or  LAND  during  which  landings  or  takeoffs 
on  other  runways  may  have  created  new  tieups  for  "this"  runway,  LAND 
and  TOFF  again  determine  the  first  time  the  runway  is  free  (from 
FREER)  . Then  the  flight  may  land  or  depart,  which  in  the  DELCAP  model 
implies  tieing  up  the  appropriate  points  for  a period  of  time  sufficient 
to  maintain  the  required  separations.  LAND  or  TOFF  then  reschedules 
NXTOP,  and  the  cycle  continues.  When  a tieup  is  no  longer  in  force, 
the  routine  FTIEUP  destroys  it. 
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Four  routines  do  not  appear  in  this  list,  since  they  are  mainly 
for  accounting  purposes.  The  BEGIN  event  (see  Figure  3.3.2)  starts 
the  simulation,  and  schedules  the  event  ENDS  which  prints  the  simu- 
lation output  and  stops  execution.  The  routine  (HOUR  (see  Figure 
3.3.3)  updates  the  current  hour  for  output  of  delay  and  throughput, 
and  reschedules  GEN  for  the  Poisson  parameter  for  the  new  hour. 

The  routine  PRINT  records  the  delay  and  throughput  information  at 
touchdown  for  landings,  and  at  start-of-roll  for  takeoffs.  The 
sections  which  follow  describe  each  of  the  event  routines  shown  in 
Figure  3.3.1. 

3.3.1  Event  EXGEN.  This  event  creates  exogenously -determined 
flights  provided  by  the  user.  This,  or  the  stochastic  generation 
processes  or  both,  may  be  used  for  a particular  run.  When  inputting 
the  information  for  the  routine  EXGEN,  the  user  must  supply  for  each 
flight:  the  hour,  minute,  and  second  of  entrance  into  the  system, 

whether  this  flight  is  a takeoff  or  a landing,  the  runway,  the  air- 
craft type,  and  (for  a takeoff)  the  departure  path,  all 
in  the  format  described  in  Appendix  A.  The  SIM3CRIPT  programs  read 
these  flights  one  at  a time  at  the  proper  simulated  time.  Therefore, 
there  is  no  limit  on  the  total  number  of  flights  as  long  as  the 
number  simultaneously  active  (including  both  those  generated  by 
EXGEN  and  those  produced  by  GEN)  is  sufficiently  small  to  fit  in  core. 

(For  a simulation  run  with  20  runways,  100  aircraft  types,  and  10 
departure  paths,  there  could  be  about  6,000  flights  active  at  any  given  time. 
This,  which  is  permitted  in  the  present  model,  is  far  beyond  the  capacity 


-72- 


Figure  3,3.2  Flowchart  of  Event  BEGIN 
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Figure  3.3.3:  Flowchart  of  Event  CHOTJR 


of  any  existing  airport  to  handle.) 

Figure  3.3.4  provides  a flowchart  for  the  EXGEN  event  routine.  For  a 
landing,  the  array  TIN  stores  the  time  the  current  flight  could  (in-  the  absence 
of  other  traffic)  first  cross  the  outer  marker  after  flying  from  its  hand- 
off  point.  A takeoff’s  flight  plan  becomes  active  about  13  to  15 
minutes  before  its  scheduled  departure.  In  the  model  this  time 
period  is  divided  into  two  segments,  so  that  takeoffs  are  scheduled 
about  the  same  time  before  start  of  roll  as  landings  are  before 
touchdown.  The  first  of  these  time  segments  (about  10  minutes), 
which  may  be  thought  of  as  representing  the  time  between  when  the 
flight  plan  becomes  active  and  when  the  aircraft  is  cleared  to 
leave  its  gate,  is  added  to  the  current  time  and  stored  in  TIN. 

(The  second  segment  , about  5 minutes,  may  be  thought  of  as  repre- 
senting a time  interval  between  when  the  aircraft  is  ready  to  leave 
its  gate  and  when  it  could  start  its  roll  down  the  runway;  it  will 
be  described  in  greater  detail  in  the  section  on  the  TOFF  routine.) 

After  calculating  the  appropriate  TIN,  the  EXGEN  routine  files 
the  newly  generated  flight  into  the  appropriate  queue.  There  are 
two  queues  for  each  runway,  one  for  landing  aircraft,  the  other  for 
takeoffs.  The  queues  are  organized  in  a first-in-first-out  manner. 

This  means  there  is  no  sequencing  by  aircraft  type;  when  a slew 
aircraft  precedes  a faster  one,  the  latter  is  not  permitted  to  over- 
take the  former,  even  if  it  could  reach  the  outer  marker  first 
without  thereby  delaying  the  slower  plane. 

Each  flight  must  remain  in  the  queue  until  its  TIN.  Filing 
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flights  into  the  queue  about  10  minutes  before  they  could  actually  cross 

the  outer  marker  or  leave  a gate  provides  a means  for  identifying 

the  aircraft  type  of  the  flight  that  follows  the  current  flight.  This 

allows  calculation  of  the  proper  tieup  time  to  ensure  that  two  aircraft 

remain  separated  by  the  required  distance.  This  distance  depends  on  the  speeds 

of  both  aircraft  involved,  and  so  cannot  be  calculated  until  the  type 

of  the  second  plane  has  been  determined. 

If  the  queue  was  empty  before  the  present  flight  was  added  to  it, 
the  NXTOP  routine  is  scheduled  to  occur  at  TIN , which  is  the  first 
instant  when  this  flight  could  be  removed  from  its  queue.  The  NXTOP 
routine,  which  schedules  the  next  operation  (landing  or  takeoff)  for 
a particular  runway,  thus  occurs  in  one  of  two  circumstances:  either 

(1)  a landing  or  takeoff  has  just  occurred,  or  (2)  the  runway  has  been 
idle  but  there  is  now  a new  flight  available  for  it.  Case  (1)  will  be 
described  later  in  conjunction  with  the  NXTOP,  LAND  and  TOFF  routines. 

In  case  (2), which  is  detected  in  the  EXGEN  routine,  the  appropriate 
queue  will  have  been  empty  before  the  flight  was  filed  in  it.  There- 
fore the  NXTOP  routine  is  scheduled  for  when  the  flight  is  first 
available  to  land  or  take  of.  However,  an  earlier  NXTOP  may  have  been 
scheduled  in  LAND  or  TOFF,  since  the  other  queue  may  not  be  empty. 

In  this  situation,  NXTOP  is  scheduled,  but  when  it  occurs  the  next  operation 
will  already  be  defined  (NEXT  + 0)  and  the  NXTOP  routine  will  be  terminated. 
This  means  that  NXTOP  may  be  scheduled  more  often  thar  necessary.  The 
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programming  alternative  was  the  coding  of  a much  more  complicated  set 
of  tests  to  ensure  that  NXTOP  is  scheduled  only  when  necessary.  This 
did  not  seem  warranted,  in  view  of  the  lack  of  computer -storage  prob- 
blems  and  the  logical  simplicity  of  the  current  test. 

3.3.2  Event  GEN.  This  event  generates  flights  in  a Poisson 
manner.  Landings  and  takeoffs  are  generated  separately,  from  two 
different  sets  of  Poisson  parameters.  This  routine  is  first  scheduled 
by  the  BEGIN  routine.  BEGIN  schedules  two  GEN’s,  one  to  create  a 
landing  flight  and  one  to  create  a takeoff.  From  then  on,  the  GEN 
routine  schedules  the  next  occurrence  of  itself.  Therefore,  within 
GEN  we  wish  to  sample  from  the  Poisson  distribution  to  reschedule 
GEN  for  the  next  entry  (’’arrival”)  of  another  aircraft  into  the  simu- 
lated system. 

The  procedure  used  in  the  computer  for  sampling  from  a distri- 
bution is  based  on  the  fact  that  the  range  of  any  cumulative  distri- 
bution is  uniformly  distributed  over  the  interval  [0,1].  In  the 
case  here,  we  have  assumed  Poisson  generation,  so  the  probability 
of  an  arrival  in  a time  period  of  length  dt  is  ydt  (plus  comparatively 

infinitesimal  terms) , where  y is  the  expected  number  of  arrivals  per 
unit  of  time.  Then  the  probability  q(T)  that  the  next  arrival  will 
occur  in  at  most  T units  of  time  is 

q(T)  = prob  (t  < T)  = 1 - e"^. 

Since  q is  a cumulative  distribution,  its  range  is  uniformly  distri- 
buted over  the  interval  [0,1],  We  therefore  employ  a standard  computer 
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subroutine  to  choose  a random  number  R from  this  uniform  distribution, 
and  then  find  the  T for  which  q(T)  = R,  namely 

T = -X  In  (1-R) 

where  X = 1/y.  The  next  instance  of  GEN  is  scheduled  to  occur  in  T 
time  units.  (Note  that  our  time  unit  for  the  simulation  is  the  hour, 
so  X is  the  reciprocal  of  the  number  of  arrivals  per  hour.)  Input 
to  the  simulation  contains  two  sets  of  values  for  X for  each  hour 
of  the  day,  one  for  landings  and  one  for  takeoffs.  As  noted 
earlier,  on  the  hour,  each  hour,  the  next  GENs,  one  for  a landing 
and  one  for  a takeoff,  are  rescheduled  according  to  the  X for  the 
appropriate  hour. 

In  the  event  EXGEN,  the  type,  runway,  and  departure  path  are 
provided  as  part  of  the  input.  In  the  stochastic  version  GEN,  however, 
these  three  items  are  obtained  by  sampling  from  the  appropriate 
distributions.  The  simulation  is  provided  (by  the  preprocessor)  with 
the  cumulative  distributions  of  (1)  type  of  aircraft,  one  for  landings 
and  one  for  departures,  (2)  runway  use  by  each  type  of  aircraft  for 
landings  and  also  for  departures,  and  (3)  departure  path  for  each 
runway.  The  three  functions  PTYPE,  PRWAY,and  PDF IX  perform  the 
sampling  processes. 

Figure  3.3.5  provides  a flowchart  of  the  GEN  routine.  After  re- 
scheduling the  GEN  routine  for  the  next  landing  or  next  departure 
(depending  on  the  current  operation),  and  sampling  to  obtain  a type, 
runway,  and  if  necessary  a departure  path  for  the  current  flight. 
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Figure  3.3,5:  Flowchart  of  the  Event  GEN 
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the  remainder  of  the  routine  is  the  same  as  for  the  EXGEN  routine. 

The  appropriate  value  of  TIN  is  calculated,  the  flight  is  filed  in 
its  proper  queue,  and  if  the  queue  was  empty  before  this  flight 
was  filed  in  it  then  the  NXTOP  routine  is  scheduled  at  TIN. 

3.3.3  Event  NXTOP.  This  routine  finds  the  next  operation,  landing 
or  takeoff,  which  will  occur  on  a runway.  Figure  3.3.6  provides 
a flow  chart  for  this  routine.  There  are  four  possible  operational 
procedures  (stored  in  the  variable  OPER)  available  for  any  runway: 

(1)  takeoffs  only,  (2)  landings  only,  (3)  dual  use,  alternating 
operations,  and  (4)  dual  use,  landings  take  precedence.  For  OPER  = 1 
(takeoffs  only)  or  OPER  = 2 (landings  only) , the  sequencing  of 
operations  is  trivial;  since  only  one  type  of  operation  is  allowed  on 
that  runway,  NXTOP  only  needs  to  examine  the  appropriate  queue.  If 
it  is  empty,  no  landing  or  takeoff  is  scheduled  and  NEXT  is  set 
equal  to  zero.  If  the  queue  is  non-empty,  the  appropriate  operation 
is  scheduled. 

If  OPER  = 3,  then  NXTOP  tries  to  alternate  operations.  The 
queue  for  the  operation  type  opposite  to  the  last  operation  is  examined 
first.  Let  t^  be  the  time  the  first  flight  in  the  queue  for  this  oper- 
ation could  be  scheduled.  If  TIN  for  this  flight  is  less  than  tp  then 
this  operation  is  the  one  scheduled.  However  if  t-^  equals  TIN,  the 
first  flight  in  the  queue  for  this  operation  may  not  be  immediately 
available.  Maybe  a flight  in  the  other  queue  would  be  available  earlier. 
Therefore,  the  other  queue  is  examined  in  a similar  manner.  Let  t2' 
be  the  time  the  first  flight  in  it  could  be  scheduled.  If  TIN  for 
that  flight  is  less  than  t£,  it  is  immediately  available,  and  this 
operation  is  scheduled.  However  if  the  first  flight  in  neither  queue 
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Figure  3.3.6:  Flowchart  of  the  Event  NXTOP 


is  immediately  available,  that  operation  for  which  the  flight  is 
available  first  is  scheduled.  Therefore  NXTOP  will  alternate 
operations,  except  when  the  first  flight  in  the  queue  for  the  alter- 
nate operation  is  not  immediately  available;  in  that  case  the  operation 
whose  first  flight  is  available  soonest  is  scheduled.  If  no 
flights  are  available,  NEXT  is  set  equal  to  zero  and  no  operation 
is  scheduled. 

For  OPER  = 4 the  NXTOP  routine  will  schedule  a landing,  if  the 
first  flight  in  the  landing  queue  is  immediately  available.  If  not, 
the  routine  schedules  that  operation  whose  next  flight  is  available 
first.  As  can  be  seen  in  the  flowchart  Figure  3.3.6,  the  logic  for 
OPER  = 4 is  the  same  as  for  OPER  = 3 except  that  the  landing  queue  is 
always  examined  first. 

The  NXTOP  routine  is  scheduled  in  one  of  two  instances:  (1)  the 

LAND  or  TOFF  routine  has  occurred,  or  (2)  a queue  was  empty  and  a 
new  flight  has  just  been  filed.  In  the  second  instance,  NXTOP  is 
scheduled  for  the  tiipe  TIN  at  which  the  flight  could  first  be  scheduled. 
However,  since  the  other  queue  for  the  runway  need  not  be  empty  or  a 
LAND  or  TOFF  routine  could  just  have  occurred,  another  NXTOP  may  already 
be  scheduled  for  this  runway.  To  avoid  error  because  of  having  several 
NXTOP s scheduled  at  once,  an  array  NEXT  with  an  entry  for  each  runway 
has  been  introduced.  Originally  it  is  zeroed.  When  a next  operation  for 
a runway  has  been  found  by  NXTOP,  NEXT  is  set  equal  to  1 (for  a takeoff) 
or  2 (for  a landing) . Then  NEXT  is  zeroed  in  the  LAND  or  T OFF  routine . 
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Therefore  NEXT  is  non- zero  precisely  when  a LAND  or  TOFF  is  scheduled 
but  has  not  yet  occurred.  NXTOP  proceeds  to  find  a next  operation  for 
a runway  only  if  NEXT  for  that  runway  is  zero.  This  condition  is  tested  at 
the  beginning  of  NXTOP,  and  if  NEXT  is  non- zero  NXTOP  is  immediately 
terminated. 

3.3.4  Function  FREER.  This  function  finds  the  earliest  time  a 
particular  flight  can  land  or  take  off  without  violating  the 
separation  rules.  FREER  is  first  called  in  NXTOP,  to  find  the  time 
at  which  the  LAND  or  TOFF  routine  should  be  scheduled. 

There  may  be  a time  gap  between  the  time  the  NXTOP  routine  occurs 
and  the  time  LAND  or  TOFF  occurs , during  which  other  flights  might 
add  new  tieups  which  require  postponement  of  the  operation  in  question. 
Therefore  FREER  is  called  again  from  LAND  or  TOFF,  to  determine  when 
the  landing  or  takeoff  may  actually  occur.  Figure  3.3.7  contains  a 
flowchart  of  the  function  FREER.  The  left-hand  side  refers  to  landings, 
the  upper  right-hand  side  to  takeoffs,  and  the  lower  right-hand  side 
to  both.  T is  the  maximum  of  TIN  and  the  current  time,  used  to  single 
out  for  examination  only  those  tieups  affecting  the  current  flight. 

The  array  TR  is  created  to  contain  the  time  (TMAX)  each  tieup  affecting 
the  flight  will  no  longer  be  in  force,  and  J is  a count  of  the  number 
of  entries  in  TR. 

For  landings,  both  the  set  of  tieups  (OMTI)  associated  with  the 
outer  marker  and  the  set  (THTI)  associated  with  the 
runway  threshold  are  examined.  The  time  of  tieups  in  THTI  is  trans- 
lated to  the  outer  marker  by  subtracting  off  the  amount  of  time  it 
takes  the  current  flight  to  fly  from  the  outer  marker  to  the  runway 
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Figure  3.3.7:  Flowchart  of  the  Function  FREER 
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threshold;  this  reflects  the  fact  that  the  runway  threshold  need  only 
be  free  as  the  current  flight  gets  there,  not  before.  For  takeoffs, 
only  the  set  of  tieups  (ERTI)  associated  with  the  end  of  the  runway 
are  examined.  The  time  of  these  is  translated  to  the  gate  by  sub- 
tracting off  TDMIN,  since  takeoffs  are  scheduled  before  they  leave 
their  gates  to  taxi  to  the  runway. 

If  there  are  no  tieups  affecting  the  current  flight  (i.e.  J = 0), 
FREER  is  set  equal  to  T.  If  only  one  tieup  affects  the  current  flight 
(i.e.,  J = 1),  then  TR  (1)  will  contain  the  time  at  which  that  tieup 
will  no  longer  impede  the  start  of  the  landing  or  takeoff  procedure, 
and  so  FREER  is  set  equal  to  it.  If  several  tieups  affect  the  current 
flight,  FREER  is  set  equal  to  the  maximum  of  the  TR’s. 

It  should  be  clear  from  the  previous  description  that  this  routine 
does  not  attempt  to  fit  a flight  in  between  two  others,  even  if  the  gap 
between  the  two  is  wide  enough.  To  do  so  would  require  a great  deal  more 
coding.  The  crux  of  the  difficulty  is  how  wide  a gap  is  ”wide  enough”. 

The  tieups  occurring  as  a result  of  the  inserted  flight  must  not  affect 
any  previously  scheduled  flight.  This  means  that  all  the  tieups  which 
LAND  or  TOFF  would  create  must  be  examined  to  see  if  they  would  interfere 
with  a landing  or  takeoff  already  scheduled  or  in  progress.  This  is 
similar  to  performing  the  whole  of  the  LAND  or  TOFF  routine,  and  involves 
the  additional  burden  of  identifying  the  flight  which  is  being  interfered 
with.  (It  is  no  longer  just  the  first  in  a queue.)  Therefore  the  simpler 
procedure,  of  waiting  until  the  last  tieup  is  no  longer  in  force  , was 
used  in  the  DELCAP  simulation.  Future  work  should  investigate  the  feasi- 
bility of  elaborating  this  procedure. 
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One  further  difficulty  can  arise  when  a slow  landing  follows 
(i.e.  lands  later  than)  a fast  takeoff.  NXTOP  is  called  as  soon  as 
the  takeoff  leaves  its  gate.  The  landing  therefore  is  not  permitted 
to  cross  the  outer  marker  before  then,  since  FREER  is  at  least  T 
which  in  turn  is  at  least  the  current  time  of  NXTOP.  However,  if 
the  landing  is  slow  enough  it  could  in  principle  be  scheduled  earlier, 
and  the  takeoff  would  still  be  able  to  precede  it  while  maintaining  the 
required  separation.  Therefore,  although  the  sequence  of  operations 
on  the  runway  must  be  a takeoff  followed  by  a landing,  the  sequence  of 
routines  should  really  be  LAND  followed  by  TOFF.  This  difficulty 
has  not  been  resolved,  but  in  sample  debugging  runs  it  occurred  only 
about  2 to  Vo  of  the  time,  and  added  only  about  30  seconds  extra  delay 
at  each  occurrence.  Therefore  it  does  not  seem  to  affect  the  DELCAP 
results  by  a significant  amount. 

3.3.5  Event  LAND.  The  primary  purpose  of  both  the  LAND  and  TOFF 
routines  is  to  tie  up  the  appropriate  points  in  order  to  ensure  that 
following  flights  remain  properly  separated  from  the  current  landing 
or  takeoff.  Figure  3.3.8  is  a flowchart  of  LAND.  LAND  removes 
the  first  flight  from  the  landing  queue  for  the  appropriate  runway. 

Then  it  calls  FREER  to  find  when  the  runway  and  final  approach  path 
are  first  free  so  that  this  flight  may  cross  the  outer  marker. 

The  separation  rules  which  apply  to  a landing,  and  their  imple- 
mentation, are  discussed  below: 

(1)  No  two  aircraft  may  occupy  the  same  runway  at  the  same  time. 
This  rule  is  inplemented  by  tying  up  the  runway  threshold  (for  landings) 
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Figure  3.3.8:  Flowchart  of  the  Event  LAND 
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or  the  end  of  the  runway  (for  takeoffs)  for  the  time  the  current 
landing  will  occupy  the  runway. 

(2)  Two  landings  must  be  separated  by  a minimum  distance  (called 
SEPLL,  in  DELCAP) . We  assume  a constant  nominal  final -approach 
speed,  depending  on  aircraft  type.  Therefore,  the  point  at  which  two 
landings  are  closest  while  always  maintaining  the  required  separation 
depends  on  the  relative  speeds  of  the  two  planes.  If  the  first  is 
faster,  they  will  be  closest  when  the  first  crosses  the  outer  marker. 

In  this  case  the  outer  marker  is  tied  up  for  the  time  it  will  take 
the  second  to  fly  SEPLL.  If  the  second  is  faster,  the  two  planes 
will  be  closest  when  the  first  just  touches  down.  In  this  case  the 
runway  threshold  is  tied  up  from  touchdown  of  the  first  until  that 
time  plus  the  time  for  the  second  to  fly  SEPLL. 

(3)  A landing  must  be  separated  from  a preceding  takeoff.  The 
separation  required  depends  on  whether  the  landing  aircraft  has  Pi  stance 
Measuring  Equipment  (DME)  . If  not,  the  landing  may  not  pass  a certain 
fix  (called  the  departure/ arrival  fix)  before  the  takeoff  starts. 
Therefore,  if  a landing  has  passed  this  fix,  no  takeoff  may  occur  until 
the  landing  has  cleared  the  runway,  and  so  the  end  of  the  runway  is 
tied  up  from  the  time  the  landing  passes  the  departure/arrival  fix 
until  touchdown.  (The  end  of  the  runway  is  already  tied  up,  for  the 
period  the  landing  will  occupy  the  runway;by  virtue  of  separation  rule 
(1)  above.)  If  the  landing  does  possess  DME,  however,  then  the  two 
aircraft  (landing  and  preceding  takeoff)  need  only  be  separated  by 
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a required  distance  (called  SEPTL  in  DELCAP) . The  standard  present 
value  of  the  departure/arrival  fix  is  4 miles  from  the  end  of  the 
runway,  and  that  for  for  SEPTL  is  2 miles.  As  noted  above,  the 
final -approach  speed  is  treated  as  constant.  Under  the  assumption  of 
a single  constant  acceleration  for  a takeoff  on  the  ground  and  in  the 
vicinity  of  the  airport,  the  distance  the  landing  must  be  from  the 
takeoff  when  the  latter  starts  its  roll  is 

SEPTL  + 0.5  V2  • ROTT/S, 

where  V is  the  speed  of  the  landing,  S is  the  liftoff  speed  of  the 
takeoff,  and  ROTT  is  the  runway  occupancy  time  for  the  takeoff.  (This 
formula  is  derived  in  Appendix  F.)  The  end  of  the  runway  is  therefore 
tied  up  from  the  time  the  landing  passes  this  point  until  touchdown 
time. 

Tying  up  a point  is  accomplished  in  the  simulation  by  creating 
a temporary  entity  called  a TIEUP,  with  attributes  TMIN,  the  time  the 
tieup  goes  into  force,  and  1MAX,  the  time  the  tieup  is  no  longer  in 
force.  The  TIEUPs  are  filed  in  one  of  the  sets  OMIT,  THTI , or  ERTI,  which 
are  scanned  in  FREER  to  decide  when  the  runway  and  final  approach  path 
airspace  are  free.  Once  the  TIEUP  is  no  longer  in  force,  it  is  removed 
by  the  FTIUP  routine  which  is  scheduled  in  LAND  as  the  TIEUP  is  created. 
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In  addition  to  tying  up  points  on  the  same  runway,  points 
on  interfering  runways  must  be  tied  up.  Two  arrays  RPT  and  TPT 
control  these  interferences  in  the  DELCAP  simulation.  For  each  runway 
and  interference,  RPT  contains  the  runway  being  interfered  with,  and 
TPT  contains  the  type  of  interference.  There  are  six  types  of 
interference : 

1.  Landings  on  one  runway  must  be  separated  from  landings  on  the 
other  runway  by  SEPLL. 

2.  Landings  on  the  one  runway  must  be  separated  from  preceding 
takeoffs  on  the  other  runway  in  the  same  manner  as  that 
described  in  (3)  above. 

3.  Takeoffs  on  the  one  runway  must  be  separated  from  following 
landings  on  the  other  as  described  in  (3)  above. 

4.  Takeoffs  on  the  one  runway  must  be  separated  from  takeoffs 
on  the  other  runway  by  the  same  separation  as  takeoffs  on 
the  same  runway. 

5.  Takeoffs  on  the  two  runways  are  independent  if  they  diverge, 
but  must  be  separated  if  they  do  not. 

6.  The  two  runways  intersect. 

Types  1,  2,  and  6 apply  to  landings.  Tieups  for  interference 
types  1 and  2 are  computed  in  a manner  similar  to  (2)  and  (3)  above. 

For  intersecting  runways,  a takeoff  or  landing  on  another  runway  may 
not  be  on  the  runway  between  the  time  the  current  landing  touches  down  and 
the  time  it  passes  the  intersection  or  turns  off,  whichever  occurs  first. 


-91- 


The  time  for  an  aircraft  to  travel  from  touchdown  to  an  intersection 
a distance  D from  the  end  of  the  runway  is 
(1/A)  (-V  + A/2  + 2 AD) 

where  v is  the  landing  speed  and  A is  the  acceleration  of  the  landing. 

We  assume  A is  constant,  so 

A = (Vj  - v) /ROTL  < 0, 

where  ^ is  the  turnoff  speed  of  the  landing,  v is  the  final  approach  speed, 

and  ROTL  is  the  runway  occupancy  time.  This  formula  is  derived  in 
Appendix  G. 

The  RPT  and  TPT  lists  are  scanned,  and  appropriate  tieups  are 
initiated  to  maintain  required  separation  between  the  current  landing 
and  operations  on  other  runways.  As  each  tieup  is  created,  it  is  filed 
into  the  set  for  the  point  being  tied  up.  At  this  same  time,  an  FTIUP 
is  scheduled  to  destroy  the  tieup  once  it  is  no  longer  in  force. 

Once  all  the  necessary  tieups  have  been  created,  the  LAND  routine 
sets  NEXT  = 0 and  schedules  NXTOP  for  the  time  the  current  landing  crosses 
the  outer  marker.  Then  the  delay  to  this  flight  is  calculated  as  the 
difference  between  the  time  it  crosses  the  outer  marker,  and  TIN 
(which  is  the  first  time  it  could  cross  the  outer  marker  were  there 
no  other  aircraft  present) . The  PRINT  routine  is  scheduled  at  the 
touchdown  time  for  this  landing.  PRINT  adds  the  delay  to  this  flight 
to  the  total  delay,  and  increments  the  number  of  landings  for  the  correct 
hour.  Since  all  tieups  to  maintain  separation  from  this  landing  have  been 
created  and  since  the  delay  for  this  flight  has  been  calculated,  the  flight 
is  no  longer  needed,  so  it  is  destroyed.  This  conpletes  our  description  of  the 
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landing  routine.  The  takeoff  routine  performs  similar  tasks  related 
to  takeoffs. 

3.3.6  Event  TOFF  - Figure  3.3.9  is  a flowchart  of  the  TOFF 
routine.  Much  of  it  is  similar  to  the  LAND  subroutine.  The  first  flight 
is  removed  from  the  landing  queue  and  FREER  is  called  to  ascertain  the  first 
time  the  flight  can  taxi  to  takeoff.  Tieups  are  created  to  maintain 
separation,  both  on  the  same  runway  and  on  others  where  there  is  inter- 
ference. NXTOP  is  scheduled  for  the  time  specified  by  FREER,  the  delay 
is  calculated,  and  the  flight  is  destroyed.  Thus  the  overall  structure 
of  TOFF  is  similar  to  that  of  LAND. 

Takeoffs,  however,  are  special  in  one  way.  They  enter  the  system 
about  15  minutes  before  scheduled  takeoff.  The  TOFF  routine  occurs 
about  4 minutes  before  takeoff.  The  reason  for  this  early  scheduling 
of  takeoffs  can  best  be  described  here,  in  the  context  of  the  TOFF 
routine.  Takeoffs  are  scheduled  about  4 minutes  early  so  that  scheduling 
of  takeoffs  is  compatible  with  scheduling  of  landings.  Landings  need  to 
be  scheduled  before  touchdown,  since  they  must  be  properly  separated 
from  other  operations  along  the  whole  of  the  final  approach  path.  If 
takeoffs  were  scheduled  only  at  start -of -roll , a following  landing 
could  be  scheduled  no  earlier  than  that  start-of-roll.  In  other 
words,  the  following  landing  could  not  cross  the  outer  marker  until  the 
preceding  takeoff  had  started  its  roll.  It  would  greatly  complicate 
the  model  if  landings  and  takeoffs  for  one  runway  were  scheduled  in  an 
order  different  from  that  in  which  they  occur  in  LAND  and  TOFF. 
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By  scheduling  takeoffs  early,  landings  and  takeoffs  can  be  treated  in 
the  same  manner.  As  noted  above,  there  is  still  a residual  difficulty 
when  a very  slow  landing  follows  a fast  takeoff,  but  for  the  most  part, 
scheduling  takeoffs  early  permits  proper  sequencing  and  scheduling  on 
a dual-use  runway. 

One  may  still  ask,  "why  generate  takeoffs  15  minutes  early?” 

Phg  figure  15  is  of  course  somewhat  arbitrary , but  it  is  necessary  to 

generate  takeoffs  at  least  3 to  5 minutes  (depending  on  the  separation 
rules)  before  they  are  scheduled  by  TOFF.  When  calculating  the  tieup 
duration  needed  to  maintain  separation  from  following  aircraft,  it  is 
necessary  to  know  the  departure  path  and/or  type  of  the  following  aircraft. 
If  the  second  takeoff  will  immediately  diverge  from  the  path  of  the  first, 
for  instance,  they  need  only  be  separated  by  1 minute.  Otherwise  they 
need  to  be  separated  by  a greater  time  interval.  Therefore  takeoffs 
have  to  be  generated  as  far  ahead  (in  time)  of  scheduling  in  TOFF  as 
the  greatest  time  separation  required  between  aircraft. 

The  careful  reader  may  wish  to  inquire  whether  this  procedure  is 
indeed  not  too  artificial.  We  note  in  response  that  these  time  intervals 
can  be  interpreted  in  terms  of  real  events.  The  15 -minute  interval 
may  be  thought  of  as  the  minimum  time  ahead  of  departure  at  which  a flight 
plan  can  be  filed.  Such  a minimum  time  is  in  fact  required  at  the  more 
congested  airports,  and  as  more  terminals  become  congested  this  practice 
will  become  more  widespread.  Also,  with  the  addition  of  computer  processing 
of  flight  plans,  a minimum  filing  time  is  quite  likely.  The  4-minute 
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time  between  scheduling  and  takeoff  may  be  thought  of  as  the  time  for 
the  aircraft  to  leave  its  gate,  taxi  to  the  runway,  and  complete  final 
checkout.  In  the  model,  queuing  for  takeoff  would  then  occur  before  leaving 
the  gate,  although  at  most  terminals  gate  space  is  limited  and  there 
are  parking  ramps  for  waiting.  This  is  another  instance  of  a situation 
in  which  we  are  interested  in  the  length  of  a time  interval  but  not 
in  where  the  aircraft  is  during  that  interval.  We  would  be  interested 
in  where  the  aircraft  actually  is  only  if  this  were  to  affect  whether 
the  aircraft  could  turn  onto  the  runway  when  the  runway  is  free.  The 
DELCAP  model  does  not  include,  in  its  present  form,  any  ground  operations. 
Therefore,  the  delay  figures  do  not  include  delays  incurred  during  ground 
operations.  Future  model  modifications  might  address  this  additional 
source  of  delay. 

To  return  to  our  discussion  of  the  TOFF  routine,  we  will  now 
describe  the  separation  rules  applying  to  a takeoff  and  their  implementation. 

(1)  No  two  aircraft  may  simultaneously  occupy  the  same  runway. 

This  rule  is  implemented  in  the  same  manner  as  it  was  in  LAND.  The 
runway  threshold  and  the  end  of  the  runway  are  tied  up  from  start  of 
roll  to  liftoff. 

(2)  Separation  between  departing  aircraft  depends  on  the  departure 
paths  being  followed  by  those  aircraft.  The  precise  rules  governing 
separation  between  takeoffs  are  contained  in  Terminal  Air  Traffic 
Control . pp.  96-97.  The  required  separation  depends  on  the  distance  to 
the  point  of  divergence  of  departure  paths.  The  separation  is  implemented 
in  the  model  through  the  use  of  an  array  SEPTT  which  depends  on  the  two 
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departure  paths  involved.  For  every  pair  of  departure  paths,  SEPTT 
contains  the  separation  time  required  between  start  of  roll  for  two 
aircraft  bound  along  those  paths.  All  the  separation  rules  are  stated 
in  terms  of  time  separation,  except  for  one  distance  separation.  In 
the  present  scheme,  this  rule  has  to  be  approximated  by  a weighted 
average  of  the  times  for  takeoffs  of  various  types  to  fly  the  required 
separation  distance.  The  standard  values  for  SEPTT  from  the  preprocessor 
are:  1 minute  for  aircraft  on  different  departure  paths,  and  3 minutes 

for  those  on  the  same  path.  This  assumes  that  different  departure 
paths  diverge  immediately.  The  user  may,  of  course,  specify  his 
own  SEPTT  array  depending  on  the  departure  routes  for  the  particular 
terminal  he  wishes  to  study.  Separation  between  departures  on  different 
runways  will  be  discussed  below. 

(3)  A takeoff  must  be  separated  from  a succeeding  landing.  The 
process  here  in  TOFF  is  similar  to  that  described  in  separation  (3)  of 
LAND.  If  the  landing  has  DME,  the  runway  threshold  is  tied  up  from  start 
of  roll  until  that  time  plus 

(l/S) (SEPTL  +0.5  S2  ROTT/V) 

where  S is  the  landing  speed,  V is  the  liftoff  speed  of  the  takeoff,  and 
ROTT  is  the  runway  occupancy  time  of  the  takeoff.  If  the  landing  does 
not  have  DME,  the  runway  threshold  is  tied  up  from  start  of  roll  of  the 
takeoff  until  the  landing  could  have  flown  from  the  departure /arrival 
fix  to  touchdown. 
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Each  tieup  created  is  filed  in  the  appropriate  set  ERTI,  for 
the  end  of  the  runway,  or  THTI  for  the  runway  threshold.  Along  with 
each  tieup,  the  routine  FTIUP  is  scheduled  for  when  the  tieup  is  no 
longer  in  force. 

TOFF  also  ties  up  points  on  interfering  runways  in  order  to 
ensure  that  the  required  separation  from  the  current  takeoff  is 
maintained.  Of  the  six  types  of  interference  listed  in  the  description 
of  the  LAND  routine,  four  pertain  to  takeoffs: 

3.  Takeoffs  on  one  runway  must  be  separated  from  following 
landings  on  the  other  runway. 

4.  Takeoffs  on  one  runway  must  be  separated  from  takeoffs  on  the 
other  runway  by  the  same  time  as  takeoffs  on  the  same  runway. 

5.  Takeoffs  on  the  two  runways  are  independent  if  they  diverge, 
but  must  be  separated  if  they  do  not. 

6.  The  two  runways  intersect. 

Tieups  for  types  3 and  4 for  different  runways  are  computed 
in  the  same  manner  as  separations  (3)  and  (2)  above  for  one  runway. 

Tieups  for  type  5 are  computed  in  a manner  similar  to  that  of  separation 
(2)  above,  except  that  a second  array  SEP2  is  used  instead  of  SEPTT. 

SEP2  contains  time  separations  required  between  aircraft  on  different 
runways  which  take  the  same  departure  path.  Type  6 is  handled  for 
takeoffs  in  the  same  manner  as  for  landings.  The  threshold  and  end 
of  the  second  runway  are  tied  up  from  the  time  the  takeoff  starts  its 
roll  until  it  has  passed  the  intersection. 
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The  remainder  of  the  takeoff  routine  is  the  same  as  the  landing 
routine.  NXTOP  and  PRINT  are  scheduled,  delay  is  calculated,  and  the 
flight  is  destroyed. 

3.3.7  Event  FTIIIP  - This  event  destroys  a tieup  as  soon  as  it  is 
no  longer  in  force.  A flow  chart  appears  as  Figure  3.3.10.  These 
"erasures'*  free  computer  storage  for  new  flights  and  tieups,  and 
make  searching  the  sets  in  FREER  easier.  Since  the  sets  OMTI,  THTI, 
and  ERTI  are  ordered  by  TMAX  (the  time  the  tieup  is  no  longer  in 
force),  FTIUP  only  needs  to  remove  and  destroy  the  first  tieup  in 
the  appropriate  set . 

This  concludes  our  routine -by -routine  description  of  the 
simulation  program.  We  will  now  describe  the  input  required  and 
output  produced.  Any  SIMSCRIPT  program  requires  a "system  specifications 
card"  and  an  initialization  deck  specifying  the  number  of  permanent 
entities  and  the  size  and  initial  values  of  each  of  the  main  variable 
and  arrays.  The  preprocessor  provides  the  initialization  deck.  A 
user  who  prefers  not  to  use  the  preprocessor  (and  so  must  prepare 
his  own  initialization  deck  instead)  should  refer  to  S DISCRIPT,  A Simulation 
Programming  Language,  pp.  115  to  128, for  a further  description  of  the 
initialization  deck  and  its  format.  We  will  describe  the  system 
specification  card  here,  though,  since  it  must  be  provided  by  the  user: 
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Figure  3.3.10:  Flowchart  of  the  Event 
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Columns 


Contain 


1 

6 


11-12 

17-18 

23-24 


1 (one) 

P - if  the  user  desires  printing  of 
the  initialization  deck.  Otherwise, 
leave  blank. 


50 

60*)  time  unit  is  hours 

60j 


36  8 (number  of  tape  unit  containing 

initialization  deck) 

42  8 (number  of  tape  unit  containing  exogenous 

events) . May  be  another  unit  if  EXGEN  is 
used,  but  first  event  must  be  BEGIN. 


In  addition  to  the  initialization  deck,  the  user  may  provide 
deterministic  traffic  for  input  to  the  EXGEN  routine.  This  input  must 
be  in  SIMSCRIPT  exogenous -event  input  format.  The  first  exogenous  event 
must  be  BEGIN  (event  type  1),  and  the  rest  may  be  EXGENs  (event  type  2), 
The  format  required  is  given  in  Appendix  A. 

Sample  simulation  output  appeared  in  the  earlier  Figure  2.2.1. 

It  includes  the  number  of  operations  generated,  the  number  performed, 
total  delay,  and  average  delay  per  aircraft  broken  down  by  hour-of-day 
and  by  operation.  Other  outputs  are  in  principle  readily  available,  but 
since  the  simulation  has  never  been  run  in  other  than  a debugging 
environment,  i.e.  to  determine  which  outputs  are  operationally  preferred, 
the  current  set  is  all  that  the  present  coding  provides.  Queue 
statistics,  such  as  average  length  of  queue,  could  easily  be  gathered. 
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Any  of  the  statistics  could  be  gathered  by  runway  or  by  aircraft  type. 
The  present  output  should  therefore  be  regarded  as  illustrative  of 
model  capability,  and  not  as  the  only  ones  available. 

This  concludes  our  description  of  the  model  programs.  The  next 
chapter  will  describe  running  the  model,  and  outputs  from  illustrative 
runs . 
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4.  OUTPUTS  FROM  ILLUSTRATIVE  RUNS 


During  the  course  of  the  current  work,  the  DELCAP  model  has  been 
run  primarily  to  test  its  components.  The  results  of  several  of  these 
runs  will  be  presented  here.  It'  should  be  noted  that  the  scope  of  the 
work  to  date  limited  ’’data  collection”  to  use  of  easily  available 
published  data;  we  were  unable  even  to  get  a complete  set  of  data  for 
any  one  airport,  and  the  present  phase  of  this  model  development  effort 
included  neither  validity  checks  nor  sensitivity  analyses.  Therefore, 
the  reader  should  view  the  ’’results”  given  in  this  chapter  as  examples 
of  model  capability,  the  outputs  of  model-testing  runs,  rather  than 
of  ’’application”  or  ’’production”  runs. 

We  will  report  three  sets  of  computations.  The  first  describes 
a parallel  runway  configuration  under  three  different  operational 
procedures.  The  second  is  the  24-hour  run  based  on  Atlanta  Airport 
(ATL)  which  was  used  as  an  example  in  Chapters  2 and  3.  The  third 
is  a run  based  on  the  John  F . Kennedy  International  Airport  (JFK) . 

The  discussion  of  each  case  will  be  accompanied  by  a specification 
of  the  associated  input  parameters . 

The  parallel  runways  for  the  first  set  of  runs  are  assumed  to 
be  between  3500  and  5000  feet  apart,  which  under  current  rules  means 
that  a landing  on  either  runway  must  be  separated  from  all  other 
landings . Takeoffs  on  one  runway  do  not  interfere  with  landings  or 
takeoffs  on  the  other.  Three  different  operational  procedures  define 
the  three  cases  studied  in  this  set  of  runs: 
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Runway  1 

Runway  2 

Case  1: 

Takeoffs 

Landings 

Case  2: 

Both 

Landings 

Case  3: 

Both 

Both 

The  traffic  mix  and  types  used  for  all  three  cases  are  given  in  Figure 
4.1.  The  same  stream  of  traffic  is  generated  in  the  three  cases. 

In  Case  1,  all  takeoffs  were  assigned  to  runway  1 and  all  landings 
to  runway  2.  In  Case  2,  50%  of  the  landings  were  assigned  to 
each  runway  but  takeoffs  only  to  runway  1.  In  Case  3,  50%  of  the  takeoffs 
and  landings  were  assigned  to  each  runway.  Other  than  this,  the  only 
difference  among  the  three  runs  was  the  operational  procedure.  In  Case  1, 
OPER  = 1 on  runway  1 and  OPER  = 2 on  runway  2.  In  Case  2,  OPER  = 3 on 
runway  1 and  OPER  = 2 on  runway  2.  In  Case  3,  OPER  = 3 on  both  runways. 
(Recall  that  OPER  = 3 means  that  landings  and  takeoffs  are  alternated  when- 
ever the  appropriate  operation  can  take  place  immediately;  otherwise  the 
operation  which  can  take  place  first,  does  take  place  first.)  The  outputs 
of  the  runs  refer  to  a one -hour  period  during  which  the  expected  numbers 
of  landings  and  takeoffs  are  each  30.  The  simulation  was  run  for  one  hour 
previous  to  recording  output  in  order  to  preload  the  system. 

Results  for  the  three  runs  are  tabulated  in  Figures  4.2  and  4.3. 

Since  all  landings  must  be  separated  by  the  same  3 miles,  permitting 
landings  on  both  runways  could  increase  throughput  only  if  runway 
occupancy  time  were  a more  critical  factor  than  a 3 -mile  separation 
rule.  A glance  at  the  data  in  Figure  4.1  shows  that  runway  occupancy 
time  for  either  a landing  or  a takeoff  is  less  than  the  time  for  any 
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SPEEDS  (KNOTS)  RUNWAY  OCCUPANCY  (SECONDS) 

TYPE  DESCRIPTION  MIX  % LANDING  LIFTOFF  LANDING  TAKEOFF 
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NUMBER  OF  OPERATIONS  PERFORMED 


LANDINGS 

TAKEOFFS 

TOTAL 

CASE  1 

32 

28 

60 

CASE  2 

30 

11 

41 

CASE  3 

28 

27 

55 

F igure  4.2: 

Throughputs,  First  Set 

of  Runs 

AVERAGE 

DELAY  PEP  AIRCRAFT  (MINUTES) 

LANDINGS 

TAKEOFFS 

ALL 

CASE 

1 

11.25 

8.74 

10.08 

CASE 

2 

13.19 

50.03 

23.07 

CASE 

3 

17.09 

19.22 

18.14 

Figure  4.3:  Mean  Delays.  First  Set  of  Runs 
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landing  aircraft  to  fly  3 miles,  so  that  the  separation  rule  is  a more 
stringent  requirement  than  the  rule  prohibiting  two  aircraft  on  the  same 
runway.  Hence,  no  increase  in  throughput  can  be  gained  by  allowing 
landings  on  both  runways.  This  is  illustrated  by  the  results  in 
Figure  4.2,  where  the  number  of  landings  actually  decreased  when  they 
were  allowed  on  both  runways.  The  decrease  stems  from  the  fact  that 
landings  must  be  separated  not  only  from  other  landings,  but  from 
takeoffs  on  the  same  runway  as  well.  In  Case  1 there  are  no  takeoffs 
on  the  same  runway  as  landings,  so  this  rule  never  comes  into  play. 

In  Case  2,  half  the  aircraft  land  on  runway  1 and  so  interact  with  the 
takeoffs  on  that  runway.  In  Case  3 all  landings  interact  with  takeoffs 
and  so  the  landing  throughput  is  cut  still  further. 

In  Case  2,  the  number  of  takeoffs  is  drastically  reduced.  Since 
takeoffs  can  only  occur  on  runway  1,  and  half  the  landings  also  occur 
on  that  runway,  it  is  not  surprising  to  find  the  number  of  takeoffs 
cut  by  more  than  half.  When  takeoffs  are  allowed  on  both  runways  (Case 
3),  their  number  increases  to  almost  its  level  in  Case  1. 

Case  1 provides  the  least  delay,  as  well  as  the  greatest  through- 
put. Since  landings  must  always  remain  separated  by  3 miles  from  other 
landings,  landing  delay  can  only  increase  when  landings  and  takeoffs 
are  allowed  on  one  runway.  Takeoff  delay  increases  dramatically,  to 
50  minutes  per  aircraft,  in  Case  2 (where  only  one  runway  handles  take- 
offs, and  landings  also  use  that  runway).  When  both  takeoffs  and 
landings  are  allowed  to  use  both  runways  (Case  3)  , landing  delay 
is  increased  over  Case  2 by  about  4 minutes  per  aircraft,  while 
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takeoff  delay  is  reduced  about  30  minutes.  It  is  difficult  to 
determine  the  exact  sizes  of  these  delays  from  the  input  since  they 
depend  on  the  traffic  mix,  the  runway  use  distribution,  and  the 
distribution  of  departure  paths. 

The  major  conclusion  which  seems  to  emerge  from  this  exercise 
is  that  --at  least  for  this  particular  airport  with  this  particular 
traffic  level  --  under  the  current  separation  rules,  the  best  on 
the  other.  Of  course  no  such  rule  should  be  inflexibly  imposed 
on  real  situations;  if  the  controller  is  presented  with  two  takeoffs 
desiring  to  leave  at  the  same  time,  and  there  is  a large  enough 
gap  in  the  landing  stream,  he  clearly  should  allow  one  of  the 
two  takeoffs  to  use  the  runway  ordinarily  reserved  for  landings. 

An  additional  observation  from  the  preceding  analysis  is  that 
the  distribution  of  departure  fixes  all  can  have  a substantial  effect 
putting  these  items,  and  they  must  be  taken  in  account  when  inter- 
preting the  results. 

The  other  two  output  sets  described  in  this  chapter  have  a 
common  aircraft  description,  given  in  Figure  4.4.  The  first  of  the 
two  is  the  Atlanta  Airport  run  which  was  used  as  an  example  earlier. 
The  traffic  mix  for  this  run  is  given  in  Figure  4.5,  and  the  airport 
description  for  our  hypothetical  version  of  ATL  in  Figure  4.6. 

The  results  are  tabulated  in  Figure  4.7. 


-108- 


SPEEDS [KNOTS)  RUNWAY  OCCUPANCY (SECONDS) 

LANDING  LIFTOFF  LANDING  TAKEOFF 
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Figure  4.5:  Traffic  Mix  for  Run  Set  II 


AIRPORT  CONFIGURATION  FOR  ATL  AIRPORT 


Number  of  Runways  = 3 

RUNWAY  1 (9L)  - Takeoffs  only 

RUNWAY  2 (9R)  - Landings  only 

RUNWAY  3 (15)  - Dual  Use,  Alternating  Operations 

Runways  9L  and  15  intersect  at  a point  2400  feet  from  the  end  of 
Runway  9L  and  1677  feet  from  the  end  of  Runway  15. 

Runways  9R  and  15  intersect  at  a point  5997  feet  from  the  end  of 
Runway  9R  and  6520  feet  from  the  end  of  Runway  15. 

Runways  9L  and  9R  are  semi -dependent  parallels  - Simultaneous 
arrivals  are  prohibited. 


Figure  4.6:  Airport  Description  for  Run  Set  II 
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The  ATL  airport  configuration  consists  of  a pair  of  offset 
parallels  4400  feet  apart,  plus  a crossing  runway.  However, 
about  96%  of  the  traffic  uses  one  or  the  other  of  the  two  parallels. 
Since  the  parallel  runways  are  less  than  5,000  feet  apart,  all 
landings  must  be  separated  by  3 miles  regardless  of  which  runway 
they  employ.  The  parallels  are  operated  in  the  manner  of  Case  1 
of  run  set  I,  one  for  landings  and  one  for  takeoffs.  The 
simulation  was  started  at  7 a.m.  and  was  preloaded  an  hour  before 
delay  and  throughput  were  recorded.  Therefore  the  first  hour  for 
which  delay  and  throughput  are  recorded  is  the  one  labeled  9 in 
the  output. 

Since  aircraft  are  generated  about  15  minutes  before  landing 
or  start-of-roll,  the  first  landings  and  takeoffs  recorded  in 
hour  9 were  actually  generated  during  hour  8.  Similarly,  at  the 
end  of  the  simulation  in  hour  8,  some  takeoffs  and  landings  have 
been  generated  but  not  yet  performed.  Although  the  expected 
number  of  aircraft  generated  in  hour  8 at  the  beginning  of  the 
simulation  is  equal  to  that  at  the  end,  the  actual  numbers  in  any 
particular  sample  run  need  not  be  the  same.  This  explains  the 
apparent  discrepancy  of  one  more  takeoff  performed  than  was  generated. 

Since  delay  and  throughput  are  recorded  at  touchdown  or  start- 
of-roll,  the  average  delay  per  aircraft  for  an  hour  is  calculated 
as  total  delay  for  that  hour  divided  by  the  number  of  operations 
performed  in  that  hour.  For  this  run,  the  average  delay  per  aircraft 
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was  much  too  high  to  be  tolerated  at  any  actual  airport.  However, 
as  noted  earlier  (in  Section  2.2.5),  the  traffic  levels  employed 
are  taken  from  total  traffic  (VFR  and  IFR)  at  San  Antonio  Airport; 
the  true  traffic  levels  and  peaking  characteristics  at  ATL  may  be 
quite  different. 

The  third  set  of  run  outputs  to  be  discussed  in  this  chapter 
refer  to  an  approximation  of  John  F.  Kennedy  International  Airport 
(JFK).  The  traffic  mix  for  this  run  is  given  in  Figure  4.8.  The 
airport  configuration,  the  most  complicated  one  employed  in  these 
model  exercises,  is  portrayed  in  Figure  4.9;  Figure  4.10  shows 
how  it  appears  on  the  preprocessor  output. 

Runways  4L  and  4R  are  close  parallels  (less  than  3,500  feet  apart), 
while  runways  31R  and  31L  are  wide  parallels  (more  than  5000  feet  apart) . 
Runway  32  (which  cannot  be  located  solely  from  the  information  given 
to  the  simulation)  is  shown  in  proper  position  in  Figure  4.10.  This 
is  a good  example  of  a case  in  which  more  information  than  is  needed 
by  the  model  would  be  required  to  produce  pictorial  output.  The  model 
only  needs  the  interference  patterns . We  know  runways  32  and  31R  interfere 
on  both  landings  and  takeoffs,  but  since  they  do  not  intersect  we  do  not 
not  need  to  know  where  they  are  in  relation  to  one  another.  We  also  know 
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Figure  4.8:  Traffic  Mix  for  Run  Set  III 


4R 


Figure  4.9;  Pictorial  Description  of  JFK 


AIRPORT  CONFIGURATION  FOR  JFK  AIRPORT 


Number  of  Runways  = 5 


RUNWAY  1 (31L) 
RUNWAY  2 (31R) 
RUNWAY  3 (4L  ) 
RUNWAY  4 (4R  ) 
RUNWAY  5 (32  ) 


Takeoffs  only 

Dual  Use,  Alternating  Operations 
Dual  Use,  Landings  Take  Precedence 
Landings  only 

Dual  Use,  Alternating  Operations 


Runways  31L  and  4L  intersect  at  a point  2096  feet  from  the  end  of 
Runway  31L  and  3427  feet  from  the  end  of  Runway  4L. 

Runways  31R  and  4L  intersect  at  a point  1288  feet  from  the  end  of 
Runway  31R  and  10748  feet  from  the  end  of  Runway  4L. 

Runways  31L  and  31R  are  independent  parallels  - simultaneous  oper- 
ations are  permitted. 

Runways  31R  and  32  are  dependent  - No  simultaneous  operations  are 
permitted. 

Runways  4L  and  4R  are  dependent  parallels  - No  simultaneous 
operations  are  pemitted. 


Figure  4.10:  Airport  Description  for  Run  Set  III 
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runway  4R  is  parallel  to  runway  4L,  that  4R  does  not  intersect  either 
31R  or  31L,  and  that  4R  and  4L  are  separated  by  less  than  3500 
feet,  but  do  not  have  to  know  exactly  how  far  apart  4R  and  4L 
are  or  if  their  endpoints  are  offset. 

Results  of  run  set  III  are  given  in  Figure  4.11.  Again  this 
is  a 24-hour  run,  from  8 a.m.  one  day  to  8 a.m.  the  next  with  the 
hour  from  7 to  8 the  first  day  run  to  preload  the  system.  The 
same  traffic  distribution  was  used  in  run  sets  II  and  III, and 
since  the  random  number  sequence  and  starting  times  were  the  same, 
the  exact  same  traffic  sample  was  obtained.  As  can  be  seen  from 
the  output,  landing  delay  for  JFK  is  greatly  reduced  relative  to 
ATL.  However,  takeoff  delay  is  much  too  great.  This  is  probably 
due  to  the  distribution  of  runway  use:  89%  of  all  takeoffs  use 

runway  31L,  while  another  9%  use  32  and  only  1%  use  31R.  (Again 
it  should  be  noted  that  these  are  hypothetical  data,  which  for 
greater  realism  should  probably  be  modified  to  put  more  takeoffs  on 
runway  31R.)  Also,  85%  of  all  takeoffs  are  bound  on  the  same  departure 
path,  tending  to  increase  average  takeoff- takeoff  separation  requirements 
and  hence  mean  takeoff  delays.  This  latter  feature,  however,  may 
reasonably  reflect  the  effects  of  the  restrictions  governing  use 
of  the  crowded  New  York  area  airspace;  real  New  York  data  would 
be  needed  to  verify  this. 
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This  is  the  last  of  our  illustration  model  run  sets.  The 


reader  will  have  observed  that  the  set  of  outputs  presented  was 
rather  restricted,  including  only  delay  and  throughput  information, 
broken  down  only  by  operation  and  hour  of  day.  Any  of  these 
statistics  could  also  have  been  recorded  by  runway  or  by  aircraft 
type.  If  the  average  number  of  passengers  per  aircraft  of  each 
type  were  provided  to  the  model,  average  delay  per  passenger  could 
be  computed,  broken  down  by  any  of  the  above  categories.  A frequency 
distribution  showing  the  number  of  aircraft  delayed  by  up  to  5 
minutes,  by  between  5 and  10  minutes,  between  10  and  15,  etc.  can 
be  computed  and  output  in  a graphical  foim  if  desired.  (The  exact 
size  of  the  recording  interval  for  such  a distribution  would  of 
course  be  a user- specified  parameter.)  In  addition  to  delay  and 
throughput  statistics,  queue-length  statistics  could  also  be 
gathered.  The  average  or  the  maximum  number  of  aircraft  waiting 
could  be  recorded  by  runway  and/or  by  operation  and/or  by  hour  of 
day.  All  of  these  items  are  available  with  some  recoding  of  both 
the  preprocessor  and  the  simulation.  Because  the  present  version 
of  DELCAP  has  not  as  yet  been  run  in  a production  environment, 
the  format  and  content  of  output  most  useful  in  that  environment  are 
not  yet  known.  Designing  the  "production"  output  options  is  one 
of  the  areas  which  must  be  included  in  future  work  on  the  DELCAP 
model. 
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Finally,  we  wish  once  again  to  emphasize  that  the  DELCAP 
model  has  so  far  been  run  for  debugging  and  logic  testing  purposes 
only,  in  exercises  not  including  the  validation  checks  or 
sensitivity  analyses  required  for  genuine  applications.  That 
such  further  resource -consuming  and  time-consuming  steps  could  not  be 
executed  during  the  present  phase  of  the  effort  was  not  surprising, 
but  without  them  the  work  which  was  accomplished  is  left  in  a 
frustratingly  tentative  and  tenuous  status.  For  example,  time 
did  not  permit  an  intensive  search  for  maximally  complete  and 
consistent  data  to  be  used  in  validation  runs.  Such  a search 
should  be  the  first  task  in  any  future  DELCAP  efforts;  one  cannot 
confidently  interpret  or  utilize  results  from  an  unvalidated  model. 
Once  DELCAP  has  received  this  basic  checkout,  sensitivity  analyses 
should  be  performed  to  investigate  the  effects  on  throughput  and 
delay  of  such  variables  as:  aircraft  mix,  operational  procedure, 

runway-use  distribution,  diurnal  traffic  distribution,  runway 
occupancy  times,  aircraft  speeds,  and  separation  rules.  These 
analyses  will  not  only  provide  a valuable  insight  into  the  effects 
on  throughput  and  delay  of  variation  in  the  airport  parameters, 
but  will  also  provide  guidelines  for  the  accuracy  needed  in 
collection  of  data  for  input  to  DELCAP. 
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In  a more  positive  vein,  we  may  note  that  the  DELCAP  model 
has  now  produced,  with  an  acceptably  small  expenditure  of  computer 
time,  delay  and  throughput  figures  for  a complicated  runway 
configuration  with  an  appropriately  high  traffic  level.  The  kinds 
of  input  data  required  by  the  model  have  been  found  in  the  published 
literature,  or  at  least  can  in  principle  be  secured  without  a great 
data  collection  effort.  The  illustrative  runs  and  analyses  reported 
in  this  chapter  have  shown  that  DELCAP  can  be  a useful  tool  in  gaining 
insight  into  the  roles  and  interactions  of  separation  rules,  airport 
configurations  and  operating  procedures,  and  traffic  distributions  as 
they  affect  delay  and  throughput. 
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5 . RECAPITULATION  AND  NEXT  STEPS 


In  this  report  we  have  described  the  present  version  of  the 
DELCAP  simulation  model  and  its  preprocessor,  which  are  currently 
operational  on  the  UNTVAC  1108  computer  at  the  National  Bureau  of 
Standards.  DELCAP  has  been  tested  on  several  different  runway 
configurations,  and  these  tests  support  our  expectation  and  intention 
that  it  be  applicable  to  a wide  variety  of  runway  configurations.  The 
model  (preprocessor  included)  takes  only  about  12  seconds  to  simulate 
a day’s  activity  at  a major  airport. 

The  DELCAP  model  is  envisioned  as  a planning  and  analysis  tool. 

To  that  end,  we  adopted  the  "model  as  little  as  you  can"  philosophy 
of  computer  simulation,  and  designed  a preprocessor  to  permit  the  user 
to  utilize  standard  data  sets  whenever  desired  and  to  input  other 
data  in  an  easily  prepared  format.  The  simulation  model  includes 
only  those  elements  of  the  airport  system  which  affect  throughput  and 
aircraft  delays,  and  is  based  on  the  idea  of  an  interference  point,  one 
of  those  points  on  the  path  of  a landing  or  takeoff  (in  the  neighborhood 
of  an  airport  or  the  surface  of  the  runway)  where  the  presence  of  one 
aircraft  inpedes  the  free  progress  of  another  aircraft  because  of  required 
separation  between  the  two.  The  simulation  contains  two  interference  points 
for  landings,  namely  the  outer  marker  and  the  runway  threshold,  and  one 
such  point  for  takeoffs,  the  end  of  the  runway  at  which  the  takeoff  starts 
its  roll.  The  model  deals  in  detail  only  with  the  times  at  which  an 


aircraft  passes  these  interference  points;  flight  paths,  holding  patterns 
and  takeoff  queues  are  not  represented  explicitly.  Only  the  interferences 
among  aircraft,  which  dictate  when  a flight  may  pass  the  interference 
points  along  its  path,  are  treated  in  detail  in  the  DELCAP  simulation 
since  these  interferences  suffice  to  determine  the  throughputs  and  the 
delays  which  are  to  be  measured  by  the  simulation. 

Two  factors  had  to  be  balanced  in  the  design  of  the  preprocessor: 
flexibility  of  input  versus  ease  of  input.  Since  DELCAP  is  designed 
as  a tool  for  aiding  analysts  in  the  planning  process,  it  must  be 
easy  and  convenient  for  use  by  one  whose  specialty  is  airports  rather 
than  computers.  However,  it  is  expected  that  planners  may  wish  to 
vary  almost  all  inputs  to  the  DELCAP  simulation.  Therefore,  the  pre- 
processor was  designed  to  allow  the  user  to  choose  those  types  of 
data  he  wishes  to  provide  himself,  while  still  providing  "standard" 
sets  of  data  for  all  input  groups  so  that  a complete  data  set  need 
not  be  prepared  for  each  run.  The  foimats  for  user-supplied  data  are 
designed  to  make  their  preparation  as  easy  as  possible,  and  to  allow 
easy  modification  where  a desire  for  such  modification  can  be  anticipated. 
Input  data  are  divided  into  six  groups  and  a user  may  either  insert 
(all)  the  data  of  a group  or  else  utilize  the  standard  data  for  that 
group.  For  those  groups  which  depend  on  the  airport,  a user  wishing  to 
use  standard  input  must  specify  from  which  airport’s  file  these  data 
are  to  be  drawn.  This  scheme  allows  a wide  variety  of  types  of 
analyses  to  be  made  using  DELCAP,  by  providing  a convenient  means 
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for  varying  almost  all  inputs.  However,  it  limits  the  data  needed  for 
any  one  run  to  those  which  the  user  wishes  to  differ  from  the  standard 
data  provided.  Thus  the  preprocessor  provides  both  flexibility  and  ease 
of  input. 

Our  documentation  has  described  the  current  versions  of  both  the 
DELCAP  simulator  and  its  preprocessor.  In  the  course  of  these  descriptions 
we  have  noted  natural  areas  for  future  work  on  the  DELCAP  modeling 
system.  We  will  now  list  these  areas  again,  to  give  the  reader  a 
better  idea  both  of  where  we  are  currently,  and  of  what  remains  to  be 
done  before  the  mature  DELCAP  described  in  the  "Mock  Instructions"  memo 
can  be  available. 
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5.1  Validity  and  Model  Sensitivity 


The  scope  of  the  current  work  was  too  limited  to  allow  adequate 
validity  and  model -sensitivity  tests.  Only  basic  logic-testing  has 
been  done,  to  insure  that  the  model  does  in  fact  perform  as  it  was 
designed  to  do.  Efforts  to  confirm  that  this  design  yields  satisfactory 
agreement  with  actual  system  performance  were  not  included  in  the 
present  phase.  In  order  to  do  this,  it  is  necessary  to  obtain  data 
from  existing  sources  (or  to  collect  them  specifically  for  this  purpose) , 
and  to  run  the  model  to  compare  model  outputs  with  these  collected  data. 
The  effort  would  include  preliminary  sensitivity  analyses  to  determine 
what  degree  of  agreement  between  model  outputs  and  the  observed  data 
can  reasonably  be  expected.  Such  sensitivity  analyses  will  also  point 
out  the  degree  of  accuracy  needed  in  collecting  model  input  data  in 
order  to  achieve  desired  accuracy  in  model  output.  For  instance, 
even  the  small  set  of  testing  runs  reported  in  Chapter  4 shows  the 
need  for  care  in  defining  the  operational  procedures,  the  runway  use 
distribution,  and  the  distribution  of  departure  paths. 

We  feel  that  validity  testing  is  the  next  logical  step  in 
bringing  the  DELCAP  model  into  full  operational  status.  Of  the 
two  types  of  output,  throughput  figures  should  be  more  easily  verified 
than  those  for  delay,  since  the  number  of  landings  and  takeoffs  in  a 
given  period  of  time  can  be  calculated  fairly  easily.  The  delay 
recorded  by  DELCAP,  however,  depends  on  the  description  of  the 
"system"  included  in  the  model,  and  may  not  be  the  same  as  any  other 
delay  measure  now  tabulated.  Therefore,  a special  data  collection  effort 


-124- 


might  be  needed  to  provide  an  empirical  basis  against  which  to 
check  DELCAP’s  delay  figures;  this  possibility  (and  potential 
alternatives)  must  be  explored  systematically. 

A model  whose  performance  has  not  been  checked  for  validity  cannot 
be  properly  evaluated  adjusted,  or  elaborated.  This  is  why  we  recommend 
validity -testing  of  the  present  version  as  the  next  step  in  the  process 
of  making  DELCAP  a useful  tool  for  planning.  However,  we  do  not  wish 
to  imply  that  such  testing  would  end  at  that  point.  There  are  several 
extensions  and  revisions  to  the  model  which,  we  suggest  in  the  following 
sections,  should  be  undertaken  subsequent  to  the  preliminary  validity 
checks.  Further  testing  against  real-world  data  would  be  needed  to 
insure  that  these  procedures,  too,  have  been  modeled  properly. 

Validity  checks  and  any  associated  data  collection  efforts  may 
themselves  indicate  model  changes.  The  results  of  such  checks  are 
unlikely  to  be  a clear-cut  "yes"  or  nno";  more  probably,  some  areas 
will  prove  to  be  better  represented  by  the  model  than  are  others.  Such 
findings  may  suggest  modifications  either  in  model  logic  or  in  the 
structure  of  the  data  required  by  DELCAP.  In  this  sense,  validity 
checking  is  an  on-going  process,  which  is  included  implicitly  in  the 
other  activities  suggested  in  this  chapter  and  which  can  prove  a 
major  stimulus  and  guide  to  model  improvements  . 
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5.2  Sensitivity  Analyses 


After  preliminary  establishment  of  validity  to  within  appropriate 
limits,  the  model  may  be  exercised  in  examining  the  sensitivity  of 
delay  and  throughput  to  variation  in  the  model  inputs . We  have  already 
mentioned  preliminary  model  sensitivity  work,  whose  purpose  is  to 
ascertain  the  ranges  over  which  the  model  variables  produce  reasonable 
outputs.  Such  preliminary  work  would  also  address  the  problem  of  which 
variables  the  model  is  particularly  sensitive  to,  i.e.  which  ones  produce 
the  most  noticable  effects  in  delay  and  throughput.  This  first  stage 
of  sensitivity  analysis,  conducted  in  conjunction  with  validity  checks, 
would  be  on  the  order  of  "tinkering"  with  the  model,  seeing  what  it 
will  and  will  not  do,  how  it  acts  and  reacts  under  various  scenarios. 

The  scenarios  might  or  might  not  be  real  or  realistic;  rather,  the  focus 
is  on  the  model  and  how  it  operates. 

With  the  completion  of  the  first  testing  cycle,  however,  the 
sensitivity  analysis  may  proceed  to  a second  stage,  that  of  testing 
system  sensitivity.  That  is,  with  the  validity  of  the  model’s  representation 
of  the  airport  system  established,  the  model  can  be  used  to  test  that 
system’s  reactions  to  hypothesized  patterns  of  changes  in  the  airport 
configuration  and  operating  procedures,  traffic  mix  and  levels,  and 
separation  rules . The  model  can  be  used  for  example  to  evaluate  what 
traffic  levels  result  in  average  delay  per  aircraft  of  over  20  minutes. 

The  dependence  of  throughput  on  aircraft  speed  can  be  studied.  The  object 
of  this  phase  of  sensitivity  testing  is  to  find  how  much  of  a change 
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in  throughput  and  delay  will  result  from  a known  percentage  change 
in  some  input  variable.  Responses  to  changes  in  combinations  of 
variables  can  also  be  tested.  The  results  of  such  sensitivity  testing 
can  aid  the  analyst  in  understanding  the  complex  interactions  in  the 
airport  system,  and  can  help  him  in  designing  a minimum  series  of 
runs  to  investigate  those  particular  changes  at  particular  airports 
which  he  desires  to  evaluate.  The  sensitivity  runs  may  eliminate  the 
need  for  some  runs  altogether  by  duplicating  common  requests.  They 
may  also  provide  advance  guidance  as  to  which  changes  are  most  likely  to 
achieve  the  planner’s  goals. 


-127- 


5.3  Model  Modifications 


Once  validity  of  the  model  has  been  established,  and  either  con- 
currently with  or  subsequent  to  the  sensitivity  analyses,  certain 
model  modifications  should  be  undertaken.  They  fall  into  six  categories 
(1)  investigating  the  possibility  of  modifying  the  scheduling  of 
landing  and  takeoffs  (see  Section  3.3),  (2)  revising  the  output, 

(3)  including  the  effect  of  weather  on  the  system,  (4)  investigating 
the  advisability  of  using  probability  distributions  rather  than 
single  values  for  some  of  the  variables,  (5)  the  inclusion  of  VFR 
traffic^ (6)  allowing  some  variables  to  depend  on  time-of-day,  and 
(7)  adding  some  ground  operations  to  the  model.  The  seven  items  appear 
roughly  in  what  we  feel  to  be  the  order  of  their  priorities. 

The  first  modification  is  designed  to  overcome  the  difficulty  in 
representing  a slow  landing  following  a fast  departure.  In  this  case 
the  landing  can  cross  the  outer  marker  before  the  takeoff  leaves  its 
gate,  remain  adequately  separated  from  the  takeoff,  and  land  after 
the  takeoff.  This  creates  a problem  in  the  present  model  because  the 
landing  should  be  scheduled  first,  although  the  takeoff  starts  its 
roll  before  the  landing  touches  down.  That  is,  the  landing  and  takeoff 
should  be  scheduled  in  the  opposite  order  to  their  occurrence. 

Another  objective  here  concerns  remedying  a second  difficulty 
in  the  present  model's  procedure  for  scheduling  landings  and  takeoffs. 
The  routine  FREER  scans  the  tieups  pertaining  to  a particular  flight, 
and  LAND  or  TOFF  is  scheduled  when  none  of  the  tieups  is  any  longer 
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in  force.  However,  there  may  be  a gap  between  the  tieups  sufficiently 
large  that  the  present  flight  could  be  scheduled  during  it  without 
affecting  previously  scheduled  flights.  If  so,  the  present  flight 
could  in  reality  be  scheduled  earlier  than  the  present  version  of  the 
model  permits . 

Modifying  the  scheduling  procedure  to  change  these  imperfections 
in  the  present  model  may  turn  out  to  be  a difficult  task  requiring 
major  modeling  changes  and  additions.  For  this  reason  it  was  decided 
that  the  simpler  version  of  the  model  was  the  one  to  be  produced  during 
the  present  effort.  However,  an  effort  should  be  made  at  least  to 
ascertain  the  difficulties  involved  in  resolving  these  two  scheduling 
problems . 

The  second  listed  area  of  model  modification  is  the  content  and 
form  of  the  output.  As  mentioned  previously,  the  model  has  been  run 
only  to  check  out  its  logic.  The  current  output  set  was  designed  to 
be  representative  of  the  types  of  output  readily  available  from  the 
model.  Once  the  model’s  validity  has  been  established  it  will  be  time 
to  take  a further  look  at  what  types  of  output  are  most  desirable.  For 
a well-based  decision  on  this  point,  it  is  necessary  to  have  a better 
idea  of  the  types  of  applications  for  which  the  model  will  be  used. 
Probably,  different  sets  of  output  will  be  most  relevant  for  different 
applications . In  this  case  a large  variety  of  output  would  be  made 
available,  with  the  user  free  to  specify  which  sets  he  desired. 

This  procedure  would  require  another  specification  by  the  user,  but 
this  seems  clearly  worthwhile  if  it  would  procure  a set  of  outputs 
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much  more  tailored  to  his  particular  preferences  and  needs. 

The  last  five  model  modifications  involve  the  addition  of  features 
to  the  model.  The  first  of  these  is  the  representation  within  the  model 
logic  of  the  effects  of  weather  on  the  system.  At  present  the  only  way 
to  mirror  changes  in  weather  is  to  vary  the  parameters  describing  the 
traffic,  separation  rules  or  operational  procedures.  This  cannot  be 
done  within  a model  run,  since  the  associated  input  parameters  are 
presently  constant  throughout  each  run.  Future  modification  should 
include  options  by  which  a user  could  provide  weather  information, 
including  a wind  profile,  and  should  automate  the  parameter-variations 
resulting  from  changes  in  weather  conditions.  At  this  point  it  seems 
unlikely  that  we  would  want  to  include  automation  of  weather  variations 
so  major  as  to  force  the  airport  to  operate  in  the  opposite  direction, 
but  the  feasibility  of  even  this  capability  should  be  investigated.  Bad 
weather  also  affects  the  number  of  missed  approaches.  In  the  present  versio] 
of  the  model  there  is  no  provision  for  these  maneuvers,  but  the  possi- 
bility of  their  inclusion  in  a future  version  should  be  studied. 

In  the  present  model  version,  such  parameters  as  landing  speeds 
and  runway  occupancy  times  are  single  values,  one  for  each  aircraft 
type.  Yet  two  "identical”  aircraft,  loaded  the  same,  need  not  have 
the  same  exact  runway  occupancy  time  or  landing  speed.  These  parameters 
could  be  represented  by  probability  distributions,  presumably  with  the 
current  parameter  values  as  means. 

The  present  model  also  assumes  that  a landing  aircraft  can 
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be  delivered  to  the  outer  marker  as  soon  as  tieups  permit.  The  degree 
to  which  this  ideal  can  be  attained  depends  on  the  pilot  and  controller, 
and  is  therefore  subject  to  human  error.  Thus  there  are  many  areas 
in  the  current  model  where  a single  value  has  been  used  to  represent 
items  which  by  their  very  nature  admit  a range  of  possible  values. 

For  this  reason,  we  suggest  that  those  model  variables  which  (like 
the  ones  mentioned  above)  might  best  be  represented  by  distributions  be 
identified,  and  that  an  appropriate  distribution  for  each  be  incorporated. 
Some  of  these  distributions  may  be  made  responsive  to  parameters  not 
now  included  in  the  model,  such  as  controllability  (human  or  mechanical) 
or  weather  descriptors.  This  may  allow  a fuller  range  of  scenarios  to 
be  tested  by  the  planner,  and  should  provide  a better  representation  of 
variations  among  aircraft. 

Yet  another  model  addition  would  be  provision  for  the  inclusion 
of  VFR  traffic.  All  separation  rules  in  the  present  model  involve  IFR 
traffic  alone.  When  dealing  with  the  throughput  of  an  airport,  however, 
it  is  desirable  to  include  all  traffic,  VFR  as  well  as  IFR.  Different 
separation  rules  apply  to  VFR  traffic,  and  such  concepts  as  the  outer 

marker  for  a landing  do  not  carry  over  from  IFR  to  VFR  operations.  Ways  of 
merging  the  two  types  of  operation  within  the  structure  of  the  DELCAP 

model  should  be  investigated,  but  this  enlargement  may  require  a major 
effort. 

In  the  present  version  of  the  model  such  variables  as  user  mix, 
the  runway  use  distribution,  and  the  operational  procedure  are  constant 
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for  the  duration  of  a run.  However,  it  seems  desirable  to  vary  these 
in  a manner  similar  to  the  current  variation  in  traffic  levels.  The 
day  might  be  broken  down  into  several  periods,  and  a different  set  of 
parameters  be  provided  for  each  period.  In  this  way  a runway  handling 
landings  only  could  be  switched  to  one  handling  both  landings  and  take- 
offs at  a time  of  day  when  takeoffs  predominate.  If  during  certain 
periods  during  the  day  the  traffic  mix  contains  fewer  small  aircraft 
than  at  other  times,  this  would  be  reflected  in  the  model.  The  coding 
to  accomplish  the  dependence  on  time-of-day  is  relatively  minor,  so  that 
the  increased  flexibility  is  bought  at  a low  price. 

The  final  feature  whose  addition  to  the  model  is  proposed  is  a 
representation  of  some  ground  operations,  mainly  those  (such  as  on 
taxiways,  exit  ramps  and  holding  ramps)  which  affect  the  aircraft 
between  its  gate  and  the  runway  surface.  Gate  assignment  might  be 
included,  if  its  inclusion  can  be  demonstrated  to  be  worth  the  amount 
of  extra  input  data  required.  Some  ground  operations,  such  as  a plane 
crossing  a runway  to  get  to  the  terminal,  can  impede  landings  and  takeoffs. 
Others  may  affect  sequencing  of  operations,  such  as  when  a takeoff 
holding  area  becomes  filled  and  there  is  no  other  waiting  area  available. 
Still  others,  such  as  baggage  handling  activities,  are  clearly  beyond  the 
proper  scope  of  a model  designed  to  focus  on  aircraft  delay.  Those 
aspects  of  ground  operations  which  affect  the  delay  and  throughput 
figures  calculated  by  DELCAP  should  be  considered  for  incorporation  in 
the  model;  all  others  should  be  excluded. 
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The  seven  areas  of  modification  described  above  are  the  major 
ones  suggested  for  future  work  on  the  DELGAP  model.  Others  may  suggest 
themselves  as  the  work  goes  on.  Several  minor  modifications  have  not  been 
included  in  the  list  above.  For  example,  more  sophisticated  sequencing 
techniques,  such  as  ones  depending  on  the  number  of  landings  and  takeoffs 
waiting  to  use  a runway,  might  be  incorporated  in  the  model. 

All  such  additions  and  modifications  should  be  weighed  carefully 
before  they  are  undertaken.  The  decision  to  go  ahead  must  include  a 
balancing  of  the  additional  data  requirements,  if  any,  against  the 
benefits  to  accrue  from  the  modification.  We  reiterate  that  ease  of 
use  is  a major  goal  of  the  DELCAP  model.  The  more  decisions  the  user 
must  make,  on  choosing  a standard  data  set  versus  providing  his  own 
inputs,  the  less  convenient  the  model  is  to  him.  If  the  input  is 
one  he  would  expect  to  provide  (such  as  some  specification  of  weather 
conditions) , indeed  one  whose  absence  would  arouse  suspicion  of  the 
model's  outputs,  then  the  extra  burden  of  providing  this  data  is 
certainly  worth  it.  If  the  modification  requires  a great  deal  of  data, 
and  promises  little  change  in  the  output  figures,  the  modification  is 
much  less  desirable.  All  modifications  must  be  studied  with  this  tradeoff 
in  mind,  and  only  those  with  a favorable  "rate  of  return"  should  be 
undertaken . 
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5.4  Airport  Data  File 


In  order  to  achieve  the  operation  of  the  DELCAP  model  as 
described  in  the  DELCAP  Mock  Instructions,  it  is  necessary  to  compile  a 
data  file  containing  preprocessor  input  data  for  each  airport  (or  at  least 
each  major  airport)  in  the  U.S.  The  current  illustrative  "file" 
contains  infoimation  on  just  two  airports,  ATL  and  JFK,  much  of  it 
invented  either  wholly  or  in  part.  The  process  of  creating  the  complete 
data  file  can  be  divided  into  two  parts,  one  dealing  with  the  form 
of  the  data  (and  any  necessary  reprogramming  of  the  preprocessor) , 
and  the  second  with  the  actual  gathering  of  the  information. 

The  changes  suggested  in  section  5.3  may  necessitate  additional 
inputs  for  the  DELCAP  model.  The  validity  and  sensitivity  tests  may 
suggest  a reworking  of  the  data  group  categories  and  changes  in 
preprocessor  input  formats.  The  format  of  the  data  file  itself  is 
likely  to  be  altered  to  facilitate  easier  coding.  All  of  these 
changes  involve  some  recoding  of  the  preprocessor  program. 

The  second  activity  involved  in  creating  the  airport  data  file 
is  the  actual  collecting  and  collating  of  the  data,  and  preparing 
them  in  the  form  necessary  for  input  to  the  preprocessor.  It  is  not  known 
at  present  exactly  which  of  the  various  data  types  are  available  from 
existing  sources,  or  in  what  form.  Therefore  preparation  of  the 
file  must  begin  with  a comprehensive  search  of  data  sources,  to  ascertain 
what  data  are  available  where,  and  to  establish  if  possible  the  consistency 
of  data  from  different  sources.  This  is  a laborious  and  time-consuming 
task  in  itself,  but  even  after  data  sources  are  found  and  checked,  there 
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remains  the  effort  of  extracting  and  coding  these  data  in  the  form 
required  by  DELCAP.  It  is  unlikely  that  all  the  needed  data  will 
already  be  on  record,  so  that  some  items  will  probably  have  to  be 
collected  in  the  field.  Also,  since  DELCAP  is  designed  for  use  in 
the  planning  process,  much  of  the  input  file  will  refer  to  future 
years.  Therefore  it  will  be  necessary  to  obtain  from  existing  sources 
(or  to  project  from  current  data)  future  traffic  levels,  traffic 
mixes,  and  airport  configurations  for  the  desired  planning  years. 

Although  preparing  the  airport  data  file  needed  by  DELCAP 
is  a major  task  requiring  much  effort  and  time,  it  should  have  a payoff 
in  addition  to  its  use  for  the  model.  Such  a data  file  could  be 
examined  to  study  the  properties  of  airports  in  the  U.S..  Easily 
accessible,  it  will  provide  people  in  the  FAA  with  airport  information 

practically  at  their  finger-tips.  There  will  be  one,  self-consistent 
source  of  airport  data. 
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5.5  Conversion  of  the  Model  to  a Time-Sharing  System 


The  final  step,  in  changing  the  present  version  of  the  model 
into  the  version  described  in  the  DELCAP  Mock  Instructions,  is  that  of 
converting  the  programs  to  a time -sharing  system.  Such  a system 
would  enable  a user  to  access  the  program  from  a terminal  in  his 
own  or  a nearby  office.  He  would  need  to  know  very  little  about  the 
operation  of  a computer,  probably  only  how  to  activate  the  terminal 
and  call  up  the  program.  The  program  would  operate  in  a conversational 
mode,  asking  such  questions  as  "Do  you  wish  to  supply  airport  data?", 
and  if  the  answer  was  "No",  "Which  airport  on  file  do  you  wish 
standard  data  to  be  chosen  from?".  The  user  would  type  in  his  replies 
to  each  question  as  it  is  asked.  (The  actual  foim  °f  the  questions  is 
of  course  a matter  for  study,  and  must  be  geared  to  the  backgrounds 
of  the  users.)  Once  all  data  were  furnished,  the  model  would  be 
run  to  supply  the  delay  and  throughput  figures  requested.  The  user 
could  then  make  a few  changes  in  his  original  data  set  and  run  again, 
or  could  start  over  with  an  entirely  new  problem.  The  program  runs 
so  rapidly  that  the  results  would  be  available  while  the  user  remained 
at  the  terminal.  Several  similar  runs  could  be  made  in  a few  minutes 
to  a couple  of  hours  depending  on  the  amount  of  data  to  be  typed  in. 
This  kind  of  procedure  allows  analysis  to  be  conducted  as  the  model 
is  run.  Questions  such  as  "What  if  such-and-such  a variable  is 
changed?"  can  be  answered  on  the  spot  with  very  little  effort.  The 
analysis  procedure  is  therefore  both  quick  and  convenient. 
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This  concludes  our  list  of  future  work  to  be  done  on  DELCAP. 

Some  of  it,  such  as  the  validity  and  sensitivity  analyses,  is  necessary 
before  the  model  can  usefully  be  applied.  Other  parts,  such  as  the  model 
modifications  in  Section  5.3,  may  or  may  not  be  desirable  depending  on 
the  uses  envisaged  for  the  model.  Some  of  those  modifications  may 
of  course  be  more  desirable  than  others,  and  all  must  be  viewed  in  light 
of  the  demands  to  be  made  on  the  model.  The  data  file  would  bypass 
the  need  for  each  analyst  to  collect  and  assemble  his  own  data  set, 
and  in  addition  would  encourage  more  general  analyses  than  would  be 
undertaken  were  the  data  not  immediately  available.  Conversion  to  a 
time -sharing  system  is  not  essential,  since  the  model  could  be  used 
without  it.  However,  the  advantages  of  having  a model  at  one’s 
fingertips  without  having  to  learn  much  about  running  on  a computer 
mean  that  DELCAP  would  be  more  accessible  to  the  user  and  more  convenient 
to  his  use,  providing  him  with  a tool  which  could  really  be  a major 
aid  in  the  whole  planning  process. 
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APPENDIX  A.  INPUT  FORMATS  AND  USER  INSTRUCTIONS 


This  appendix  is  divided  into  six  sections,  (1)  preprocessor 
input  formats,  (2)  sample  preprocessor  output  (simulation  input) 

(3)  simulation  input  (system  specification  card) , (4)  exogenous 
event  tape  format  for  explicitly  scheduled  flights,  (5)  the  airport 
data  file  format,  and  (6)  the  current  sample  airport  file. 
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A. 1 Preprocessor  Input  Format 


The  first  two  cards  must  always  be  provided.  Card  one  contains 
the  times  for  the  beginning  and  end  of  the  simulation.  The  hours 
run  from  0.  (midnight)  to  23.  (11  p.m.)  and  the  number  of  minutes 

past  the  hour  goes  to  the  right  of  a decimal  point  (so  that  7:45  p.m. 
would  be  19 . 45) . 

The  second  card  contains  the  INPUT  array.  The  input  variables  are 
divided  into  six  groups.  The  user  may  provide  any  of  these  groups 
or  request  that  the  program  supply  standard  data.  Within  each  of 
the  six  groups  all  or  none  of  the  data  must  be  supplied.  The  INPUT 
array  indicates  which  of  the  groups  is  to  be  read  from  the  user.  Each 
element  of  INPUT  is  a three -character  code.  If  the  code  is  left 
blank,  the  program  will  read  user-supplied  data.  For  information  which 
varies  from  airport  to  airport,  the  three- letter  code  associated  with 
any  airport  (e.g.  JFK,  ATL)  will  cause  the  program  to  search  its  data 
tape  for  data  representing  that  airport.  If  the  tape  does  not  contain 
data  on  the  requested  airport,  an  error  message  will  be  printed  and 
the  program  will  stop.  For  data  groups  which  are  independent  of 
airport  any  code  other  than  three  blanks  will  provide  standard  data. 

The  variables  in  each  group  will  follow. 

Group  I - includes  data  about  each  type,  or  class,  of  aircraft.  It  is 
independent  of  airport.  If  INPUT (1)  is  blank,  user  must  provide  one 
card  for  each  type  (up  to  10)  with  average  landing  and  takeoff  speeds, 
average  takeoff  and  landing  runway  occupancy  times,  and  the  presence 
or  absence  of  distance -measuring  equipment.  The  largest  type  number 
must  be  placed  last,  followed  by  an  end-of-file  card.  The  next  card 
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contains  an  average  turn-off  speed  for  all  types. 

Group  II  - includes  percentages  of  each  type  of  aircraft  in  the 
takeoff  and  landing  mixes.  It  is  airport -dependent.  If  INPUT (2) 
is  blank,  two  cards  must  be  provided:  the  first  with  the  take-off 

mix,  the  second  with  the  landing  mix. 

Group  III  - contains  the  average  numbers  of  takeoffs  and  landings 
per  hour.  It  is  airport -dependent.  If  INPUT  (3)  is  blank,  user  must 
provide  data  for  every  hour  to  be  simulated  plus  one  hour  previous 
to  the  beginning, up  to  a total  of  24  hours.  The  takeoff  rates 
come  first,  twelve  numbers  to  a card,  on  one  or  two  cards  as 
needed,  followed  by  the  landing  rates. 

Group  IV  - includes  three  separation  distances, 

1)  distance  to  the  departure/arrival  fix. 

2)  radar  separation  between  airborne  landing  aircraft 

3)  radar  separation  between  a landing  and  a takeoff  from  the 
same  runway. 

All  three  distances  are  in  nautical  miles.  This  group  is  indepen- 
dent of  airport.  If  INPUT  (4)  is  blank,  user  provides  one  card  with 
these  three  distances. 

Group  V - includes  the  description  of  the  runways  and  the  operation 
of  the  airport.  If  INPUT  (5)  is  blank,  the  following  cards  mist 
be  supplied: 
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1)  number  of  distinct  departure  paths  from  the  runways. 

2)  one  card  for  each  runway,  up  to  9,  with  its  heading,  its  left/ 
right  designation  if  it  is  one  of  a set  of  parallels,  its 
operation  code  (1,  2,  3,  or  4,  see  later),  and  the  distance 

to  its  outer  marker,  followed  by  an  end-of-file  card. 

3)  one  card  for  each  runway  containing  the  time  for  each  type  of 

aircraft  to  fly  from  handoff  to  outer  marker  of  that  runway, 

4)  for  each  intersection,  the  numbers  of  the  intersecting 

runways,  the  distance,  in  feet,  from  the  first  to  the 
second,  and  from  second  to  first,  followed  by  an  end-of-file 
card. 

5)  for  each  pair  of  runways  which  are  not  independent,  the  numbers 
of  the  runways  and  the  dependence  code  (1  or  2,  see  later). 

[Note  --  this  may  change  from  VFR  to  IFR.  Two  runways  which  are 

VFR  independent  may  well  be  IFR  dependent.]  These  are  followed 
by  an  end-of-file  card. 

Group  VI  --  includes  percentages  of  each  type  of  aircraft  using 
the  runways  and  departure  paths.  It  is  airport -dependent.  If 
INPUT (6)  is  blank,  one  card  for  each  type  must  be  supplied  giving 
the  fraction  of  total  takeoffs  of  that  type  using  each  runway, 
and  the  fraction  of  total  landings  of  that  type  using  each  runway. 
[Note:  if  there  are  more  than  six  runways,  two  cards  will  be  needed 

for  each  type.]  These  are  followed  by  one  card  for  each  runway, 
giving  the  fraction  of  all  takeoffs  from  that  runway  using  each 
departure  path. 
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Card 

No. 


Column 

Nos. 


Variable 


No.  Decimal 
Places 


FORTRAN 

Format 


1 

1 - 7 

TBEG  - beginning  of 
simulation 

2 

F7.2 

8 - 14 

TEND  - end  of  simulation 

2 

F7.2 

2 

1 - 18 

INPUT  (1  - 6) , 3 columns 
per  element 

- 

6A3 

GROUP  I 

one  per 
type 

1 - 3 

number  of  type  ( < 10) 

0 

13 

4 - 6 

= 0 if  type  has  DME 

> 0 if  type  does  not  have 

DME 

0 

13 

7 - 13 

aver,  landing  speed (knots) 

2 

F7.2 

14  - 20 

aver,  takeoff  speed (knots) 

2 

F7.2 

21  - 27 

aver,  runway  occupancy 
time  - landing  -(seconds) 

2 

F7.2 

#types  + 1 

28-34 

aver,  runway  occupancy 
time  - takeoff  - (seconds) 

end-of-file 

2 

F7.2 

#types  + 2 

1 - 7 

aver,  turn  off -speed, 
all  types 

2 

F7.2 

GROUP  II 

1 

6 per 
type 

decimal  fraction  of  take- 
off mix,  of  each  type 

4 

12F6.4 

2 

same 

dec.  frac.  of  landing  mix 
of  each  type, 

4 

12F6.4 

GROUP  III 

1,  2 

6 per 
hour 

number  of  planes  taking 
off  per  hour 

1 

12F6.1 

3,  4 

same 

# planes  landing  per 
hour 

1 

12F6.1 

Card 

No. 


Column 

Nos. 


Variable 


No.  Decimal 
Places 


Fortran 

Format 


GROUP  IV 


1 - 7 

distance  to  departure/ 
arrival  fix 

2 

F7.2 

8 - 14 

required  separation  be- 
tween landing  planes  in 
air 

2 

F7.2 

15  - 21 

required  separation 
between  arrival  and 
departure 

2 

F7.2 

GROUP  V 

1 

1 - 2 

number  of  departure  paths 

0 

12 

one  per 
runway 

1 - 2 

number  of  runways 
(1  - 9) 

0 

12 

3 - 6 

heading  of  runway 

0 

14 

7 - 8 

left/right  designation 

- 

A2 

9 - 12 

operation  code:  1- takeoffs 
only,  2 -landings  only, 

3- both,  alternating 

4- both,  landings  preferred 

0 

14 

#rw  +2 

13  - 19 

distance  to  outer  marker 

Cnaut,  miles) 
end-of-file 

2 

F7.2 

one  per 
runway 

7 per 
type 

time,  in  minutes,  for 
each  type  to  fly  from 
handoff  to  outer  marker 

2 

10F7. 

one  per 

1 - 2 

first  runway  number 

0 

12 

inter- 

section 

3 - 4 

second  runway  number 

0 

12 

5 - 12 

distance  from  end  of 
first  to  intersection 
(feet) 

0 

F8.0 

13  - 20 

distance  from  end  of  se- 
cond to  intersection 
(feet) 

end-of-file 

0 

F8.0 
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Card 

No. 


Column 

Nos. 


Variable 


No.  Decimal 
Places 


Fortran 

Format 


one  per 
inter- 
ference 

1 - 2 

first  runway 

0 

12 

3 - 4 

second  runway 

0 

12 

5 - 6 

interference  code: 

1 - simultaneous 
dep/arr  and  dep/dep 
are  permitted,  given 
divergence,  but  arr/arr 
is  prohibited,  2 - all 
simultaneous  operations 
prohibited. 

0 

12 

GROUP  VI 

end-of-file 

one  per 
type 

6 per 
runway 

decimal  fraction  of  all 
takeoffs  of  type  which  use 
each  runway,  followed  by 
decimal  fraction  of 
all  landings  of  type  which 
use  each  runway 

4 

12F6.4 

one  per 
runway 

6 per 

dep. 

path 

decimal  fraction  of  all 
takeoffs  from  each  runway 
going  on  each  path 

4 

12F6.4 

r 
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Sample  Data  Deck 

Note:  b is  used  to  indicate  a blank 

bbb8.00bb20.00 

XXXJFKbbbXXXJFKJFK  Note:  This  card  indicates  that 

the  user  wishes  to  supply  only 
Group  III,  takeoff  and  landing 
rates.  There  would  follow 
at  most  4 cards. 


Group  I 

bblbblbl65 . 00bl75 . 00bb59 . 00bb37 . 00 
bb2bblbl35 . 00bl45 . 00bb52 . 00bb34 . 00 
bb3bb0bl20 . 00bl30 . 00bb45 . 00bb31 . 00 
bb4bb0bll0 . 00bl20 . 00bb38 . 00bb28 . 00 
bb5bb0bl05. 00bll5 . 00bb31 . 00bb24 . 00 

VbE0F 
bb30. 00 


Group  II 

0 . 3000b . 20bbb . 15bbb . 15bbb . 20 
b . 35bbb . 25bbb . 15bbb . lObbb . 15 


Group  III 

bbb9 . 0bbb3 . 0bbb2 . 0bbb2 . 0bbb4 . 0bbb2 . 0bbb2 . 0bbb9 . 0bb20 . 0bb23. 0bb25 . 0bb35 . 
bb40 . 0bb38 . 0bb46 . 0bb46 . 0bb51 . 0bb42 . 0bbl8 . 0bbl6 . 0bbl6 . 0bbb9 . 0bbb7 . 0bbb9 . 
bbl7. ObbbO . 0bbl5 . 0bbb5 . ObbbO . 0bbb5 . 0bbb5 . 0bbb3. 0bbl7 . 0bb29 . 0bb33. 0bb39 . 
bb47.0bb37.0bb38.0bb40.0bb51.0bb51  .0bb38.0bbl7.0bbl7.0bbll.0bbll.0bbl6. 


Note  that  the  symbol  V stands  for  a multipunch  7 8,  The  symbol 
stands  for  the  letter  0. 


0 

0 

0 

0 


-147- 


Group  VI 


1 . OObbO . ObbbO . ObbbO . Obbbl . OObbO . 0 

b.90bb0. ObbbO . lObbO . ObbbO . 50bb0 . 50 

b . 75bb0 . ObbbO . 25bb0 . ObbbO . 55bb0 . 45 

b . 50bb0 . ObbbO . 50bb0 . ObbbO . 30bb0 . 70 

b . 25bb0 . ObbbO . 75bb0 . ObbbO . 05bb0 .95 

b . 20bb0 . 65bb0 . 15bb0  .67bb0.05bb0. 28 


1 Even  though  runway  two  handles  no  takeoffs , giving  these 
data  does  no  harm,  and  makes  them  available  if  necessary. 


1 
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Group  IV 

bbb4 . 00bbb3 . 00bbb2 . 00 


Group  V 


b lbb 1 7bbbbb lbbb  8 . 5 
b 2bb  2 0 Rbbbb  2bb 1 1 . 0 
b 3bb  2 0 Lbbbb  3bbb  8 . 0 
AbE0F 

bblO . 25bbl2 . 18bbl4 . 10bbl6 . 67bbl8 . 33 
bbb9 . 50bbll . 25bbl3. 20bbl6 . 00bbl7 . 90 
bbb9 . 15bbll . 75bbl3. 33bbl5 . 50bbl7 . 40 
blb2bbb8500.bbb9000. 
bib  3bbb  2275. bbb  5430. 

AbE0F 

blb2bl  3 
blb3bl 
b2b3b2 
AbE0F 


2.  Even  though  these  data  are  not  relevant  to  runway  one,  they  should 
be  given,  and  do  no  harm. 

3.  Note  that  interference  relates  to  the  physical  relationship  among 
runways,  not  actual  interference,  since  in  this  case 
operations  on  the  runways  preclude  such  interference. 
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Sample  Preprocessor  Output  (Simulation  Input) 


A.  2 


1 

n 

n 

9 

n 

n 

n 

n 

n 

G 

0 

2 

2 

n 

0 

P 

n 

G 

n 

G 

n 

n 

0 

3 

3 

n 

n 

P 

o 

G 

n 

n 

o 

n 

0 

4 

0 

0 

P 

0 

0 

n 

n 

0 

0 

0 

3 

5 

n 

n 

P 

n 

0 

n 

n 

o 

0 

□ 

2 9 

A 

n 

1 

R 

3 

2 

n 

0 

0 

n 

0 

l n ( i 2 ) 

7 3 
7 

n 

l 

R 

3 

2 

G 

G 

0 

0 

□ 

i n ( D3 . *4 ) 

a . o n 
p 

nn 

n 

) 

9 . nnGn 

p 

1 P 
3 

• nonn 
2 

n 

n 

0 

G 

0 

1 G ( I 2 ) 

2 1 3 

9 

G 

2 P 

5 

3 

3 2 

0 

OR  FO 

12(01 

.9  ) 

* l 3 p n 

• 

l 7 2n 

• l 3 p n . 

19  3 0 

,1790 

• 1 9 30  .1^90 

.19^0  , 1590 

• 1 790 

.2090 

• 

2550 

. 209n 

1 n 

0 

1 P 

5 

3 

0 n 

0 

0 o 

10(12) 

1 1 1 

n 

0 

1 1 

n 

1 p 

5 

3 

o n 

0 

0 o 

10(03. 

9 ) 

95, nnGn 190. 

0000130, 

0000  1 

1 1 5 .0000 

9 p , 0000 

12 

0 

1 R 

5 

3 

0 0 

0 

0 0 

10(03. 

9 ) 

55,0000193, 

0000190, 

0000123.00001 

1 0 . 0 0 0 0 

1 3 

n 

1 R 

5 

3 

0 0 

0 

n 0 

10(03. 

9 ) 

• 01 

9 0 

♦ 

0 123 

0 1 OP 

.0092 

.008  1 

1 9 0 

1 

p 

5 

3 

n 

n 

n 

0 

0 

1 0 ( D3 • 9 ) 

.009  1 

.008  3 

.0^77 

,0069 

• 0058 

1 5 G 

n 

R 

n 

0 

n 

0 

0 

0 

0 

25.000 

1 6 n 

0 

p 

0 

0 

n 

o 

o 

n 

0 

9 ,000 

1 7 0 

0 

P 

0 

0 

o 

0 

0 

0 

0 

3.000 

1 8 0 

0 

R 

0 

c 

0 

0 

0 

0 

0 

2,000 

1 9 n 

1 

P 

3 

2 

o 

0 

0 

0 

0 

1 n ( 03 • 9 ) 

.1297 

. 13  3 8 

,19  3 7 

2 G 0 

2 

R 

2 

1 

5 

3 

0 

0 R 

FO 

12(01.9) 

.1900  , 

7700  .7900 

. 93nn \ 

• 

on  on 

, 

1900 

. 7 7nn  , 7900 

,9. 3001.0000 

2 1 0 

2 

R 

5 

3 

3 

2 

0 

0 R 

F 0 

12(01,9) 

.oonni . 

noon  i . on  On  \ 

,00001 

9 

r ono  1 

, 

noon 

. 9 0 0 0 ,90001 

,nnoo  ,9non 

.7000  . 

7000  1 . OnOO 

22  0 

2 

R 

5 

3 

3 

2 

0 

0 R 

FO 

12(01.9) 

.oonni  • 

oonni . noon 

, n o n n i 

, 

0000  1 

• 

0000 

’. noon  ,9oooi 

.onno  ,nnoo 

,oo on  • 

70001 ,0n0n 

23  n 

2 

R 

3 

2 

3 

9 

0 

0 R 

FO 

12(01,9) 

•3300  - 

6 7 0 0 1 .0000 

• 3 3 n 0 

• 

6 7 0 0 1 

• 

nooo 

, 75f)0  • 7500  1 

,0000 

29  ?9 

1 

Z 

3 

2 

n 

0 

0 

o 

0 

25  0 

1 

R 

3 

2 

0 

0 

0 

0 

0 

10(12) 

1 2 2 

26  n 

2 

R 

3 

2 

3 

2 

0 

0 P 

FO 

1 2 ( 0 1 , 9 ) 

,0000  , 

QOno  , 3 9 B n 

. 0000 

, 

nooo 

, 

9870 

.27601.0730 

.0000 

27  ?P 

2 

7 

3 

2 

2 

1 

0 

0 

0 

29  0 

2 

R 

3 

2 

n 

0 

0 

0 

Or 

10(12) 

3 3 0 0 

n 

non 

0 

0 

3 0 0 0 

0 

n o o 

0 

n 

12  10 

n 

0 n o 

0 

0 

30  0 

2 

R 

3 

2 

0 

n 

0 

0 

Or 

10(12) 

6 5 H G 

C 

non 

n 

0 

6 G 0 □ 

0 

0 0 0 

n 

0 

6 6 5 D 

0 

non 

n 

n 

. 2 1 70  .17^0 


• 9noru.onno 


• 9onn l • onOn 


2 

1 

3 

2 

1 

3 
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3 l 

0 1 

R 

3 

2 

0 0 

0 0 

0 

10(03. 

*4  ) 

t 0 6 n 3 

• 

0670 

. T 357 

32 

0 2 

R 

3 

*4 

3 *4 

0 0 R 

, F° 

1 2 ( D 1 

.8) 

.050n 

• 0 1 67 

. 0 1 67 

. 0 1 67 

• 0500 

0 0 1 67 

0 1 6 7 

• 0 167 

• 0500 

33 

38  1 

7 2*4 

5 

0 0 

0 0 

0 

39 

0 0 

R 

n 

0 

0 0 

0 0 

0 

8.000 

*40 

*45  1 

Z 3 

2 

0 0 

0 0 

0 

*46 

0 0 

R 

0 

0 

0 0 

0 0 

0 

32.000 

*47 

0 2 

R 

2 

1 

28  5 

0 0 R 

, F° 

1 2 ( D 1 

• *4  ) 

.0909 

. 3333 

.5000 

• 50no 

. 2500 

• 5000 

15000 

• 0909 

. 0500 

• 0*4  1 7 

• n*40O 

.0385 

. 0 2 5 n 

. 0278 

. 0 1 85 

. 0 1 85 

.0179 

. 0233 

. 0526 

.0588 

• 0588 

• 1 1 1 1 

• 07M 

.0909 

.52699.9999 

.0580 

. 20009,9999 

. 2000 

. 2000 

• 3333 

. 6667 

.0385 

.0333 

. 0263 

.0227 

. 0286 

. 0270 

.0250 

. 0 1 96 

• 0189 

.0278 

• 0588 

.0588 

• 1111 

• 1 1 1 1 

• 0526 

|*4  8 

0 o 

R 

0 

0 

0 0 

0 0 

0 

8 

*49 

0 2 

R 

3 

*4 

3 *4 

DOR 

fo 

12(01 

.8  ) 

,0  3 3 <4 

• ooon 

_ . onOo 

, oOon 

.033*4 

. 0000 

• OOOO 

.0000 

• 033*4 

50 

50  1 

7 2 

1 

0 0 

0 0 

0 

0 

0 □ 

0 

0 

0 0 

0 0 

0 

These  cards  provide  initial  values  for  all  system  variables 
and  arrays  and  permanent  entities  in  the  SIMSCRIPT  simulation 
program.  The  format  required  is  rigid  and  may  require  changing 
many  cards  to  make  a simple  data  change.  Users  interested  in 
a more  complete  description  of  the  required  formats  should 
consult  SIMSCRIPT;  A Simulation  Programming  Language , pages 


115  through  128. 
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A. 3 Simulation  Input  - the  System  Specification  Card 

Simulation  input  consists  of  the  tape  output  by  the  preprocessor 
and  one  card  supplied  by  the  user  and  called  the  system  specification 
card.  Its  format  is  as  follows: 


Column 

Contains 

1 

the  number  1 

6 

P,  if  printing  of  the  initialization 
deck  is  desired 

11  - 12 

the  number  50 

17  - 18 

the  number  60 

23  - 24 

the  number  60 

35  - 36 

the  tape  unit  the  initialization  deck  is 
to  be  read  from;  this  is  unit  8 if  the 
preprocessor  is  used 

41  - 42 

the  tape  unit  used  for  the  exogenous  events;  this  is 
unit  8 if  the  user  is  not  specifying  any 
explicitly  generated  flights. 
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A. 4 Exogenous  Event  Tape  Format  for  Explicitly  Generated  Flights 
The  first  record  must  be  for  the  BEGIN  event. 


Columns  Contain 


3 

the  number  1 

6 - 7 

the  starting  hour  for  the  simulation 

10 

the  number  0 

12 

the  number  0 

The  rest  of  the  records  describe  explicitly  generated  flights, 


one  flight  per  record. 

Columns 

Contain 

3 

the  number  2 

6 - 7 

the  hour  the  flight  enters  the  system 

9 - 10 

the  minute  of  that  hour 

11  - 12 

the  second  of  that  minute 

13  - 14 

1 if  flight  is  a takeoff,  2 if  flight 
is  a landing 

15  - 16 

the  runway  to  be  used  by  this  flight 

17  - 18 

the  aircraft  type  for  this  flight 

19  - 20 

the  departure  path  if  this  is  a takeoff 

There  should  be  an  end  of  file  after  the  last  flight  record. 
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A. 5 Airport  Data  Pile  Format 

In  all  of  the  following  the  number  of  runways  is  9,  the 
number  of  aircraft  types  is  10,  the  number  of  departure  paths 
is  5,  and  the  number  of  interferences  is  10.  Data  must  be 
provided  as  if  there  were  9 runways,  for  instance,  even  though 
there  might  be  onlv  2.  The  other  7 values  may  be  zero.  They 
are  never  used  but  are  only  place  holders  to  space  the  data 
items  properly.  The  variables  referenced  here  are  described 
in  .Appendix  B. 

record  FORTRAN 

number Contents format 

1 3 letter  airport  identifying  code  A3 


2 


CTYPE  for  takeoffs  followed  in 
the  same  record  by  CTYPE  for 
landings 


20F6.3 


3 - 4 


LAMBD  for  takeoffs  for  each  hour  12F8.6 
of  the  day 


5 - 6 


LAMBD  for  landings  for  each  hour  12F8.6 
of  the  day 


7 


number  of  actual  runways 


12 


number  of  actual  departure  paths  12 

operational  procedure  for  each  912 

runway 


heading  code  for  each  runway 


912 


number  of  interferences  for  each  912 
runway 
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record 

number 


Contents 


FORTRAN 

fomat 


8 left/right  designator  for  each  9A2 

runway 

9 Interference  code  for  each  runway  8111 

pair  (1  if  landings  on  i interfere 

with  landings  on  j but  not  with 
takeoffs , and  2 if  both  land- 
ings and  takeoffs  on  one  run- 
way interfere  with  operations 
on  the  other) 


10 

RPT  for  each  runway  and  interference 

9011 

11 

TPT  for  each  runway  and  interference 

9011 

12 

DOM  for  each  runway 

9F6.3 

13  - 

15 

FLYOM  for  each  type  for  each  runway 
(3  runways  per  record) 

30F4.3 

16  - 

20 

DINT  for  each  pair  of  runways 
(2  runways  per  record) 

18F5.3 

21 

PRWYT  for  each  type  of  aircraft 
for  runways  1 through  3 

30F4.2 

22 

PRWYL  - runways  1-3 

30F4.2 

23 

PRWYT  - runways  4-6 

30F4.2 

24 

PRWYL  - runways  4-6 

30F4.2 

25 

PRWYT  - runways  7-9 

30F4.2 

26 

PRWYL  - runways  7-9 

30F4.2 

27 

PDF IX  for  each  departure  path 
for  runways  1 through  4 

30F4.2 

28 

PDF IX  - runways  5-9 

30F4.2 
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APPENDIX  B.  MODEL  ELEMENTS  (ROUTINES,  VARIABLES,  ETC.) 


This  appendix  is  divided  into  two  sections.  The  first  lists  each 
of  the  routines , events  and  functions , and  provides  a phrase  describing 
what  each  does.  The  second  section  lists  the  names  and  descriptions 
of  variables  used  in  the  model.  The  variables  are  listed  under  the 
headings  of  entities , arrays , attributes  of  event  notices , temporary 
entities,  attributes  of  temporary  entities,  and  sets.  The  reader  should 
refer  to  Section  3.1  for  the  definitions  of  these  terms. 

B.l  Routines 

Exogenous  Events 

1.  BEGIN  - starts  the  simulation 

2.  EXGEN  - creates  explicitly  generated  flights 
Endogenous  Events 

1.  GEN  - creates  flights  in  a Poisson  manner 

2.  NXTOP  - finds  the  next  operation  (landing  or  takeoff) 
for  a runway 

3.  LAND  - creates  tieups  resulting  from  a landing 

4.  TOFF  - creates  tieups  resulting  from  a takeoff 

5.  FTIUP  - destroys  tieups  no  longer  in  force 

6.  ENDS  - prints  final  output 

7.  CHOUR  - updates  current  hour 

8.  PRINT  - records  delay  and  throughput 
Functions 

1.  PTYPE  - picks  an  aircraft  type 

2.  PRWAY  - picks  a runway 
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3.  PDFIX  - picks  a departure  path 

4.  FREER  - finds  the  first  time  the  current  operation  can 
proceed 

B#2  Variables 
Entities 

1.  0 - operation  (1)  takeoff,  (2)  landing 

2.  RW  - runway 

3.  TYP  - aircraft  type 

4.  FIX  - departure  path 

5.  H - hour 
Variables  and  Arrays 

1.  LAMBD(O)  - Poisson  distribution  parameter,  the  average 
time  (in  hours)  between  operations 

2.  OPER(RW)  - operational  procedure 

(1)  takeoffs  only 

(2)  landings  only 

(3)  dual  use,  alternate  operations 

(4)  dual  use,  landings  take  precedence 

3.  DOM(RW)  - distance  from  the  outer  marker  to  the  runway 
threshold 

4.  NPT(RW)  - greater  than  zero  if  the  runway  RW  interferes 
with  others 

5.  FLYOM(TYP)  - time  to  fly  from  handoff  to  the  outer  marker 

6.  DME (TYP)  - (0)  no  DME 

(1)  has  DME 

7.  VLAND(TYP)  - landing  speed 

8.  VTOFF (TYP)  - liftoff  speed 

9.  ROTL(TYP)  - runway  occupancy  time  on  landing 
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10.  ROTT  (TYP)  - runways  occupancy  tune  on  takeoff 

11.  VTAXI  - turnoff  speed  for  landings 

12.  DAFIX  - distance  from  departure/arrival  fix  to  the 
runway  threshold 

13.  SEPTL  - distance  which  must  separate  a landing  possessing 
DME  from  a preceding  takeoff 

14.  SEPLL  - required  inter  landing  separation 

15.  CALIN  - minimum  time  between  the  generation  of  a takeoff 
and  clearance  to  leave  its  gate 

16.  CTYPE  (0,  TYPE)  - cumulative  distribution  of  aircraft  mix 

17.  CRWYT(RW,  TYP)  - cumulative  distribution  of  runway  use 
for  takeoff 

18.  CRWYL(RW,TYP)  - cumulative  distribution  of  runway  use 
for  landing 

19.  CDFIX(RW,  FIX)  - cumulative  distribution  of  departure  paths 

20.  NEXT(RW)  - next  type  of  operation  on  runway  RW.  If 
NEXT  is  zero,  the  next  operation  has  not  been  scheduled 

21.  LAST(RW)  - the  latest  operation  on  RW 

22.  DINT(RW^,  RWj)  - distance  from  the  end  of  RW^  to  its 
intersection  with  RW. 

23.  TPT  (RW , NTPT(RW))  - type  of  tieup  on  RW  caused  by  an 
operation  on  another  runway  (see  RPT  for  which  other 
runway) : 

(1)  to  maintain  interlanding  separation 

(2)  to  maintain  a landing  separated  from  a preceding 
departure 

(3)  to  maintain  a departure  separated  from  a following 
landing 

(4)  to  maintain  departure  separation  between  completely 
dependent  runways 

(5)  to  maintain  departure  separation  on  semi -dependent 
runways 

(6)  to  maintain  separation  on  intersecting  runways 
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24.  RPT(RW,  NRPT(RW1)  - runway  tied  up  as  a result 

of  an  operation  on  RW,  Note  that  RPT  and  TFT 
together  describe  the  interference  between  runways; 

RPT  tells  which  runway  is  interfered  with  and 
TPT  tells  how, 

25.  TDMIN(RW)  - minimum  time  between  a takeoff’s 
leaving  its  gate  and  starting  its  roll 

26.  SEPTT(TIXpFDf.)  - required  separation  time  between  a 
departure  bound  on  path  FIX^  and  one  departing  the 
same  runway  bound  on  path  FIX^ 

27.  SEP2(FIX^,  FIX..)  - required  separation  time  between 

an  aircraft  departing  on  path  FIX^  from  one  runway  and  one 
departing  on  FIX^  from  a different  runway  where  the  two 
runways  are  semi -dependent 

28.  IHOUR  - current  hour 

29.  NARR(H)  - number  of  landings  generated 

30.  NDEP(H)  - number  of  takeoffs  generated 

31.  NLAND(EI)  - number  of  landings  performed 

32.  NTOFF(H)  - number  of  takeoffs  performed 

33.  DELT(H)  - total  takeoff  delay 

34.  DELL(H)  - total  landing  delay 

35.  TBEG  - time  the  accounting  for  delay  starts 

36.  TEND  - time  the  simulation  ends 

37.  GENN(O)  - the  identity  of  the  GEN  currently  scheduled  for 
operation  0 

Attributes  of  Event  Notices 

1.  RWAY  - runway 

OP  - operation 


2. 
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3,  PT  - point  tied  up 

(1)  outer  marker 

(2)  runway  threshold 

(3)  end  of  the  runway 

4.  DLAY  - delay  for  the  current  flight 
Temporary  Entities 

1.  FLT  - flight 

2.  TIEUP 

Attributes  of  Temporary  Entities 

1.  TYPE (FLT)  - aircraft  type 

2.  DFIX(FLT)  - departure  path 

3.  TIN (FLT)  - first  time  FLT  can  cross  outer  marker  or 
leave  its  gate 

4.  TMIN (TIEUP)  - beginning  of  tieup  interval 

5.  TMAX (TIEUP)  - end  of  tieup  interval 

Sets 

1.  Q(RW,0)  - landing  and  takeoff  queues 

2.  CMTI (RW)  - tieups  in  force  at  the  outer  marker 

3.  THTI(RW)  - tieups  in  force  at  the  runway  threshold 

4.  ERTI(RW)  - tieups  in  force  at  the  end  of  the  runway 
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APPENDIX  C 

LISTING  OF  THE  PREPROCESSOR  PROGRAM 
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this  Program  i g a prf.  processor  w m I c h reads  in  the  data  and 
PUTS  It  into  proper  FORM  for  USE  by  the  SIMULATION  PROGRAM. 
PARAmETFR  KR!Vs9,KTYP=10,KFIX35.K0s2*KTPT«10 
integer  OPER(KR'V) ,DMF(KTYP) ,RPT(KRW,KTPT) .TPT(KRW.kTPT) 

PF.AL  L»Mao(KO.?'l) 

0 l M E N 5 I ° N D 0 m ( K R W ) ,NPT  (KRW)  ,FlYOMIKTYP,KRW)  ,VLAND(KTYP)  .ROTL(w'TYP) 

|.VTOFF(KTyP)',ROTT(KTYP).PTYpE(KO,KTYP).pRWYT(<TYP.KR«V)1LAST(KR/M.. 

?PR«.VYL  ( KTYP  ,KR  V)  ,POF  I X ( KRW  ,KF  I X ) ,DINT  (KRVl/.KRW)  , INPUT  ( M , TDM  I N I K » A ) . 

3SfP2{Kf!X,^FTX)  , S E P T T (KFIX.KFIX)  . INTER (KRw,KRW)  , C A L I N ( K R W ) • N ( A 0 ) , 

R i m e A P ( v R l*J  ) » I L R ( K R W ) 

1 Nr  7 


C 

c 

c 

c 

70S 


son 


l 


? 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


730 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


TREG.TFND  ARF  TIMFS  of  PEGINNING  and  end  OP  SIMULATION 
EXAMPLES  aRE  O.nO  FOR  mIDNIGhT  and  17. 30  FOR  S . 3 0 P*M, 


READ(S,705)TREG.TEND 
format ( 1 o F 7 . 7 ) 

uV  R I T F ( A , S 0 o ) T R F G * T F M n , . . 

FORMaTmITHIS  SIMULATION  R h N 5 F R 0 M « F 6 . 2 , • T0»Fa.2///) 

TnrG  = ATNT(TBFG)-f(TBFG-AltJT  (TRfG)  )/fO, 
TEND*AiNT(TEN0)4(TEND-AINTfTEND))/60. 

IF  (TBFG.GT.n.)  GO  TO  1 

TRFG=TrFG+2B. 

TFND=TEND+2a. 

IF  ( TEND «LE • TRFG ) T E N n * T E N n ♦ 2 R • 

IRFG=TbEG-I . 

!MOUR»MOD(  I R F G , 2 *M  ♦ 1 
NHsTEN0-TREG>.99 
N y a - 1 

I r (NH.LT.2R)  GO  TO  2 
T l = 1 
J J = 2*4 
GO  TO  4 
I I s I H 0 U R 
lEND=TENn-#0) 

J J * M 0 D < I E N D 1 

IF  ( J J . L T . I I ) N 0 * J J 


INPUT*  I)  - LEAV/F  RLAMK  IF  tTH  DATA  GROUP  WILL  BE  SUPPLIED  BY  USER 
ANYTHING  ELSE  WILL  CAUSE  PROGRAM  TO  SUPPLY  STANDARD 
DATA.  FOR  GROUPS  2.3.S.6  SFT  INPUT  EQUAL  TO  A I R P 0 R r ID 
DATA  GROUPS  ARE  - 1)  NUMBER  AND  DESCRIPTION  OF  AIRCRAFT  TYPES 

2)  mix  of  Aircraft  types 

3)  LANDING  AND  TAKEOFF  RATES,  BY  HOijR 
M ) SEPARATION  REQUIREMENTS 

5)  DESCRIPTION  OF  AIRPORT  aNo  ITS  OPERATION 

6)  FRACTION  OF  TYPES  USING  EACH  RUNWAY  AND 
DEPARTURE  PATH 


RFAD(5,73  0>  INPUT 
FORMAT ( 6 A 3 ) 


NJTyPE  - NtJ  M R E R OF  TYPES 

OME(I)  - SET  TO  1 if  TYPF  T Has  distance  measuring  equipment 
v t o e f ( t ) - takeoff  speed  of  type  i»  in  knots 

V L A N 0 ( I ) - LANDING  SPEED  OF  Type  I . IN  KNOTS 

R 0 T L ( I i - R i j N w A Y OCCUPANCY  TIME  ON  LANDINGS  FOR  T yPE  I,  IN  SECONDS 
ROTT(I)  - Same  FOR  TAKEOFFs 
v t a x i - average  turnoff  speed  for  all  types 
AND  TO  0 IE  NOT  -163- 


IF(INPuT(|),EO.»  • ) G 0 TO  5 

DATA  NtyPEiVLAND.VT0FF.R0TL|R0TT,VTAXJ*pME/5.1‘45.^1<40.,130..1i5., 
1 98.  ,5*0.  • l 55.  , 198,  , mm  • 1 23.  # 11  0 # I 5*0.  , .pi  9 , • 01  23  . . Q l Oft  • .00*2  . . 
2.0081  .5*0.  ..0091  ,.OO83,.O077».OOM,.OO5flt5*O.,25,.3*l'.  7*0/ 

GO  TO  10 

5 REaD(5,725*END*6).  NTYPE»DME(NTYPE)  .VLAND(NTYPE)  ,VTOFF(NtYPE)  , 

1 R'OTL(NTYPE),ROTT(NTYPE) 

725  FORMAT { 2 I 3 # 9F7  • 2 > 

GO  TO  5 

6 read  ( 5 ,705  ) v taxi 
DO  7 III  ,nTYPF 

ROTL( I ) » R 0 T L ( I ) / 3 6 0 0 • 

7 ROTT ( I ) =R0TT ( n / 3 A 0 0 • 


PTYPFtl.I)  - THF  FRACTION  OF  TOTAL  TAKF0FF5  WHICH  ARE  OF  TyPE  I 
p T Y P E ( 2 , I 1 - SAME  FOR  LANDINGS 


in  IF(INPUT(2).E0.*  • ) G 0 TO  1 5 
REWIND  IN 

11  REaD(1n,600.END*300)I 
600  F09MaT { A 3 ) 

I F ( I .NE  . I nPuT ( 2 ) ) GO  TO  11 

R F A D ( I N , 6 0 5 ) ( (P T Y P E { I , J ) , J * 1 , K T Y P ) • ! * 1 * K ft  ) 

605  FORMAT ( 20F6  . 3 ) 

GO  TO  30 

15  DO  16  1*1,2 

R F A D ( 5 « 7 1 0 ) (PTYPEI  I , J ) .J*iTnTyPE) 

7 1 0 FORMAT ( 1 2F*  . q ) 

16  CONTINUE 

no  25  1*1,2 

n 0 20  J*2,NTYPE 

20  PTyPE ( I , J ) *PTYPE ( I • J-  1)  +PTYPE ( I , J ) 

IF ( I N T f ( P T Y P p ( j ,NTYPF)*#Ol  ) • l 0 0 • ) • N E • 100)WRITE (6,900)  I 
ft  0 0 EORMATf*  WARNING  - PROBABILITIES  of  all  types  for  OPERATION*, t2, 

1*  (1-LANDING,  2-TAKEOFF)  DO  NOT  SUM  TO  ONE*) 

25  CONTINUE 

LAMBD(l.I)  - AVERAGE  NUMBER  OF  TAKEOFFS  DURING  ITh  HOUR  OF  THE  DAY 
LAHB0(2fI)  - SAME  FOR  LANDINGS 


30  I F ( I NPUT { 3 ) . FO . * »)G0  TO  35 

IF ( INPUT  <3) . EQ  • INPUT (2)  )G0  TO  32 

REWIND  in 

31  READ(lN,600^END*300)I 

I F ( I • NE • INPUT { 3 ) ) GO  TO  3 1 

read ( I n , 6 o o ) i 

32  do  3 3 1*1,  K 0 

R F A D ( IN, 610)  (l  A M B D ( I ,J)  ,J«1  ,2ft) 

33  CONTINUE 

6 1 0 FORMAT ( 1 2FB . 6 ) 

GO  TO  MO 

35  IF(ND*GT.O)GO  TO  37 

00361*1,2 

RFAD(5,720)  (LAMRDI  I ,J)  ,J*I  I . U J,) 

720  FORMAT  ( 1 2F6  . l ) 

DO  36  J*  1 , 2q 

IF(LaMr0(I,J),LE»0.)G0  TO  35l 

LAMBD<  I . J ) * 1 ./lambdi  I .J) 

GO  TO  36 

35 1 L AMBD ( I , J )*9.999 

36  continue  -164- 

G0  TO  90 


37  00  3 8 ! s | , 2 

R E A D ( 5 , 7 2 H ) ( L A M R 0 ( I , J ) ,J«IHnUW|?q)  , ( L A M R 0 ( I ,J)  , j • i , n D ) 

0 0 3 8 .1*1  ,28 

1 F .(  L A M R n ( ! , J ) . L.  F.n.JGO  TO  3 7 1 
LAMRrW  I , J ) * 1 ./LAMRO(  I,J) 

GO  TO  38 

371  L&mBO( I , J ) =0, 099 

38  COMTlNuF 


o a f I x - distance  of  dep/arr  Fix  from  runway 

SFPLl.  - p A o A r?  S r P ^ T I 0 N REQUIRED  P E T W £ E N AIRCRAFT  ON  SAME  PATH 
SFPTl.  - PaDap  SEPARATION  REQUipfo  8ETWFEN  a LANDING  A/C  AND  aM  A/C 

taking  off  from  thf  runway 

Alt  THpFE  DISTANCES  ART  IN  NAUTICAL  MILES. 


80  I F ( I NPlJT  ( 8 > . FQ  , • • ) GO  TO  85 

OAF  I X = 8 . 

S F P T L * 2 . 

S E P L L ■ 3 . 

GO  TO  50 

85  REAn(5,7PS)0AFIX,SEPLL,SEPTL 


NF I X - NUMBER  OF  FlXFS 
I H F A 0 ( I ) - THp  HFADING  OF  RUNwaY  I 

It.R(J)  - FOR  PARALLEL  RUNWAYS,  THE  LEFT  OR  RIGHT  DESIGNATION 

for  example,  if  Runway  ? is  3ir,  i h e a n < ? ) • 3 l and  t l r ( 2 i * R 
opfp(I)  - opfration  r o n r for  runway  i 

C 0 n f s A R F 1-  TAKEOFFS  ONLY,  ? - LANDINGS  ONLY 
3 - 0 U A L IJ  S E , ALTERNATING  OPERATIONS 

8-DUAL  use.  landings  take  precedence 

DON ( I ) . DISTANCE  to  OUTER  mApkfR  for  runway  I 

F L Y 0 M ( T , J ) - TIME,  IN  M I N U T f S » FOR  A TYPE  I A/C  TO  F L Y FROM  H A N D 0 F F 
TO  OI.ITFR  MARKER  OF  RUNWAY  J 

DINT(I*J)  - r I STANCE  F^OM  END  OF  RUNWAY  I TO  ITS  INTERSECT  I 0 n 
WITH  RUNWAY  J,  IN  FEET 

INTFR(T,J)  - INTERFERENCE  rO^p  FOR  RUNWAYS  I AND  J 

C ° D E S ARE  1-  LANDINGS  ON  I AND  J INTERFERE  AND 

most  be  separated,  rut  simultaneous 
TAKFOFFS  ARF  PERMITTED  if  they  DlvFRGE. 
2 - N 0 SIMULTANEOUS  OPERATIONS  PERMUTED 
IF  NEITHER,  CnNPLETE  INDEPENDENCE  IS  ASSUMFD. 


50  IF ( I N P 1 J T (5)  • E Q • * • ) G 0 TO  5 5 

I F ( I^PUT (5)  • F Q . INPUT ( 3)  )GO_TO  S 8 

lF(lNPuT(5).F0*INPUT(2).ANn.lNPUT(3),E0.*  »)G0  TO  5? 
RrwlnD  hi 

5 1 R E A D f I M . A n 0 * F N 0 * 3 0 0 ) I 

IF  ( I , Nr,  lNpUT  (5)  ) G 0 TO  51 
RFiDf  I M , A 0 0 ) T 

52  DO  53  J*1 

RE  AD ( I N , AQO  ) I 

53  CONTINUE 

58  READ!  In.M5)NRW.NFJX,0PFR,IHEaD,NPT 
A 1 5 FORM  A T , A6  I 2 ) 

READ!  I N , A 2 0 ) TLR 
620  FORMAT ( J OA  2 ) 

READ!  I M , A 2 5 ) J M T F R 
R E A D ( I N , 6 2 5 ) R P T 
R E A D ( In,A25)TPT 
625  FORMAT (13211) 
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READ(lN,A05>PnM 

READ  ( I N , 6 3 Q ) ((FLY0M(J,I),J*1.KTYP)»J*1,KRW) 

A30  FORMAT  | 

READ  < T N , 6 3 5 ) ((D!NT(!,J),J*1,KRW),I*1,KBW) 

635  FORMAT  ( 1 8FS  , 3 ) 

GO  TO  1 1 n 

55  RF AD { 5 ,700 INFIX 
N R W * 0 

55  1 RFAD(5~735»FNn=55?)  1 , J HEAD ( ! > • I L R ( I)  *OPER  f I ) , DOM  ( I) 

7 3r)  FORMAT  ( I2»I<4,A?,lH*F7*2) 

WRiWsMR  m + 1 
GO  TO  5 5 1 
552D056-I*1.Nrw 

RFAD(5,705>  ( F I.  Y 0 M ( J , l ) , J * 1 , NJ  T Y P E ) 

DO  5 6 J ■ 1 , N P »* 

D I Tvl  T ( I , J ) * 0 . 

56  CONTINUE 

57  PEAD(5,71G*Fmd  = 571  ) I , J , D I NT ( I , J ) , D I N T ( J , I ) 

715  FORMAT (2T7»?r«,0) 

GO  TO  57 

571  READ(5,700.EK'D*572)  I , J , INTfR(  I , J ) 

700  FORMAT  f ! 0 I 2 ) 

GO  TO  571 
5 7 7 DO  5 9 I s 1 , N R -.»j 

DO  5ft  Js 1 , NT YPF 
5 8 flyOM(j,I)=FLYOM(j%I)/AO. 

0 0 5 9 j « 1 , N R W 

59  d!NT(I,J)*D!NT(I>J)/A076* 

DO  6 0 I * 1 , N R W 

DO  6 n J a 1 , N R w 

IF  ( I N T F R ( I ,J)  .FQ*0)G0  TO  6 r> 

TNTFR(J,I)*INTFR(I,  J) 

60  CONTINUE 

no  9o  i*i, nr w 

Ksfl 

no  8 0 J * 1 , N R w 

1 F { I NTpR ( I , J ) . FO  . 0 1 GO  TO  80 

IF  (OPER(  I ) *LT.7,0R.0PER( J)  .LT.2J60  TO  65 
K = K + t 

RPT ( I . K ) * J 
TPT(  I iK)sl 

65  I F ( 0 P E R ( I ) » F Q • 2 • 0;|R  * 0 P F P ( J 1 • E Q • 2 ) G 0 TO  70 
KsK+1 

RPT  ( I » K ) * J 
TPT(  I t < ) » *4 

I F ( I N T p R ( j *J).EQ,1)TPT(I  ,K)*5 
7 n IF(INTfR(I.J).E0*1)G0  TO  80 

IF(0PER(I)*FQ.?.0R.0PER(J).EQ.1)G0  TO  75 
KiKM 

RPT ( I . K ) a J 
TPT ( J * K ) *3 

75  IF(OPER(l)fF0.1.OR.0PFR(J).EQ#2)60  TO  80 
K = K ♦ 1 

RPT ( I i <) a J 

TPT  ( I »<)»2  -166- 

BO  CONTINUE 


no  85  J ■ 1 , N R v 

IF  ( D I N T ( I *J)  . I F • 0 . ) GO  TO  8 5 
K = K ♦ 1 

RPT ( I »K  ) « J 
TPf  ( I » K ) » A 
85  CONTiNijf 
NPT ( I ) bK 
K = K ♦ 1 

HO  8 A L»K,10 
RPT  ( I i I.  ) a Q 
TPT ( ! » L ) =0 
8A  CONTINUE 
9Q  continue 

p R W Y T ( I , J ) - T H F FRACTION  OF  ALL  TAKEOFFS  OF  TYPE  I A/C 

which  use  runway  j 

P R W Y L ( I , J ) - THE  SAME  FOR  LANDINGS 

p o f i x ( i t j ) - the  fraction  of  all  takeoffs  from  runway  i 

WHICH  ARE  GOING  TO  DEPARTURE  FIX  J 


1 10  I F { I NPtJT  ( 6 ) . FQ  . * * ) G 0 TO  llS 

IF(INPUT(6).E0.INPUT(5))60  TO  \ J M2 

I r ( INPiiT  ( A)  • E 0 • INPijt  { 3)  • A N n , INPUT  (S)  • E Q • * ♦ ) G 0 TO  118 

_IF(INPuT(A)tF0.!NPuT(2).AN0.lNPuT<3).E0#*  *.AND.lNPllT(5).Fo', 

1 * • ) G 0 TO  112 

REWIND  IN 

111  PEAO(lN,600*ENDs300)I 

IF(I.Ne.INPUT(A))GO  to  111 
RF  AO ( I N , A 0 0 ) I 
11?  DO  113  J*  1 , 8 
R E A 0 ( I m , 6 n 0 ) I 
113  C 0 N T I N ij  E 
118  00  1181  Jrl ,18 

READ!  I N , 6 0 0 ) I 

1181  continue 

1 M 2 DO  1 1 r A I I ■ 1 , K R W , 3 
J J= I I ♦ 2 

R E A D ( I N , A 8 0 ) ( (PRWYTI  I , J ) .1*1  .10)  , J * I I , J J ) 

R E A 0 { IN.A80)  ( ( P R W Y L ( I , J ) .1*1  » 10)  , J«  I I ,JJ) 

1183  CONTINUE 

READ  ( I N , A 9 0 ) (<PDFIX(!,J),J=1,KFIX),!*1^8) 

READ  (IN.A^O)  ( ( Pdf  I X ( ! , J ) , J* 1 ,KF  I X ) , J «5 ,KRW ) 

A 8 0 FORMAT ( 3 0 F 9 . 2 ) 

GO  TO  185 

115  DO  120  J*1»NTYPE 

120  R E A D ( 5 j 7 1 0 ) (PRWYT(j,I  ) .1*1  , N R W ) , ( P R W Y L C J • ! ) . I ■ 1 ,NRW) 

0 0 1 2 l I = 1 . N R W 

READ(5*710)  (pDFTX(  I , J ) , J * l , N F I X ) 

121  CONTINUE 

DO  122  I = 1 . M R W 
DO  122  Jal.NTYPF 

!F(PRWyT(J»I).GT.  o.  .AND.  0PfR(I)*EQ.?)WRITEU,830)J,I 
830  FORMAT ( • WARNING  - THERE  IS  A POSITIVE  PROBABILITY  THAT  A T Y P r * . 

112,  • aircraft  will  take  off  From ♦/ 1 2X  ,* runway *,  I 2,  * . which  handles 

2 landings  only*) 

IF(PRAYL(J»I).GT.0..AND.0PER<I).EQ.i)WRITE<A,A80)J,I 
880  FORMATi*  WARNING  - T H E * E IS  A POSITIVE  PROBABILITY  THAT  A TYPE*. 

ii2,*  aircraft  will  land  on  •/ i ?x ,» runway ».  1 2 ,* , which  handles  takf 
?offs  only  • ) 

122  CONTINUE 
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no  12  0 Ja  1 • N R W 


DO  123  J«2,NF1X 

123  Pdf  I X ( T , J ) *PDF T X ( I . J- 1) ♦PDF  I X ( I , J ) 

IF(lNTf(PDF!X(!,NFIX  M.Oi)*lOO.).NE,inn)WRlTEC6,ft50>I 

flsn  format  f * warning  - probabilities  of  Takeoffs  from  runway*, i 2 , 

1*  GOlNr,  TO  all  FIXES  DO  NOT  SUM  TO  ONE*) 

12  0 continue 

I F ( N R W . E 0 . I ) G 0 TO  139 
DO  130  I«1,NTYPE 
DO  125  J«2»NRW 

PRWYL(  T , J ) *PRW YL ( I ,J-1  ) ♦ P R W Y L ( I , J ) 

1 ?S  PRWYT ( I , J ) * D R W Y T ( I . J - 1 ) ♦PRWYT ( J # J ) 

IF(INT((PRWYL(!.NRW  )+.01)*l00.).NE.100)WRlTE(A,Rl0)I 
810  FORMATf*  warning  - PROBABILITIES  OF  A TYPE*,  12,  • AIRCRAFT  landing 
ION  all  runways  nO  MOT  sum  to  one*) 

IF  ( InT  ( {PRWYT  ( I ,NRw  )^,01)*ln0.).NE#in0)WRlTE(^P20)I 
P2n  FORMATft  warning  - PROBABILITIES  OF  A TYPE*, 12,*  AIRCRAFT  T A K T N G 

i o f f from  all  runways  do  not  Sum  to  one*) 

130  CONTINUE 

10b  DO  ISO  I a 1 ,60 

150  N ( I ) » I 

D 0 9 S T « l , N R w 

TdmIN(  I ) * ( D 0 M ( I ) / V L A N 0 ( 1 ) ) *PT  YPE ( 2 • 1 ) 
no  95  J«2,NTYPE 

93  TDMlN(I)S{D0M(I)/VLAND(J))*fPTYPE(?,J)-PTYPE(2;j-i))4TDMlN(I) 

D 0 1 0 0 I = 1 , N R W 

C A L I N ( T )»fLYOM(i  ,1  ) • P T Y P E ( 2 , 1 ) 

DO  100  J=2iNTyPF 

too  C4LIN(n»rLY0M(T,J).(PTYPE(2,J)-PTYPE(?,J-!)i+CALtN(n 

DO  105  I a 1 , NRW 
L AST ( I ) =2 

IF(0PEr(I),E0.1  ) L AST ( I ) ■ 1 
105  CONTINUE 
139  DO  MO  I « 1 , N F I X 
DO  MO  js  1 , NF  I X 
SEPTT ( j ,J)s,0lA7 
I E ( I . Eo . J ) SEPTT ( I , J ) a . Q5 
S F P 2 ( I ,J)rO, 

IF(  I ,Eq.J)SEP?(  I , J ) a , o 3 3 0 
MO  CONTINUE 


L «0 


Mag 

'«R!TF(m,900)N(  I ) 
WRITf<M,900)N(2) 
WRITe(m,900)N(3) 
WRITf(*,900)NM) 
WRITF(M,900)N(S) 
WRlTE(M,920)N(6) 
WRtTE<M,930)N(7) 

WRlTr(Mt920)N(8) 

DO  I S 5 Mi, NRW 


N ( 2 ) 

NRW 
NT  YPE 
NF  I X 
N ( 20  ) 

NRW,N  { 2 ),,  OPER  ( I ).  MJ  ~ NRW  ) 
NRW,n(2)  , (dOM{  I ) , I a i ,NRW) 
NRW.NI2)  , (NPT(  I ) , I a 1 ,NRW) 


I P ( NP  T ( 1 )*EQ.n)NPT(  I Ml 
1 5S  CONTI NUE 

WRITE(h,90O)M(9).NTYPE,N(3),N-RW,N(2),((FLYOM(j,I) 
1 J* 1 , NT  YPE ) 

WRITE(M,920)N(!0),NTYPE,N(.i),(DME(I),Ia|*NTYPE) 
LVRlTE(M,930)N(ll),NTYPE,N(3)i(VLAND(I)1MllNTYPE) 
WR I TE ( m , 930 ) N ( 1 2 ) ,nTyPE ,N ( 3 ) , ( vTOFF ( I ) # I a j ,NT YPE ) 

W R I T E ( m , 9 3 0 ) N ( 13)  , N T Y P E , N (**  ) , ( R 0 T L ( I ) ,Ial  j N T Y PE  ) 

WRlTE(Mt930)N(M),NTYPE,N(3),(R0TT(I),Ml,NTYPE) 


I a 


N R W ) , 
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W R I T F ( H , 9 1 0 ) N ( ! 5 ) , V T A X I 
•JVR  I TE  i M ,9  1 o ) N ( 16)  .DAFIX 
WR  I TE ( M , 9 1 0 ) N ( 1 7 ) * SFPLL 
WRtTFlM,9lO)N(18),5EPTL 

w R ! Tr  ( M , 930  ) N < l o ) , mpw  , N ( 2 ) ! ( C A|_  I N ( I ) , ! a 1 . NRW  ) 

iJVRlTF(M,990)N(20>  , N ( 7 ) ,N ( 1 ) ,NtyPE,N(3)^  ( ( PT YPE ( I , J ) . J«  1 . NT  YPF  1 . 


1 ! * 1 . 7 ) , 

WRITF(m,990)N(  7 \ > , N T Y P E , N < 3 ) iNRW.Nl  2)  , ( ( P R W Y T ( I , J ) , J « 1 .NRW)  , 

1 T s 1 , N T Y P E ) 

lVR|TE<M#9qO)N|(??>,NTYPF,N<3)#NRW,NC2).(<PRWYL(!tJ».J*I.NRW). 
I I a 1 • N T Y P E ) 

W R I T E ( M , 9 9 0 ) M ( 2 3 ) , N R W , N ( 2 ) , N F I X , N ( 9)  , ( ( P D F 1 X ( I . J ) . J ■ 1 , N F I X ) * 


\ tat  « N R A ) 

WRITE(M,9S0)N(2'4).N(29),N(1  ) » N R W , N ( 7 ) 
WR!TE(m,9?0)N(?5),NRW#N(2),(1-aST(1)|I  = 1.nRW) 

« R I T E ( M , 9 9 0 ) M ( 7 6 ) , N P W . N ( 2 ) , N R W , N < 2 ) , ( ( D 1 N T ( I , J ) , J « 1 .NRW)  .1  = 1 ,mR*I 

W R I T E < M . 9 5 0 ) N ( 2 7 ) . N ( 2 8 > . N C ? ) » N R W , N ( 2 ) , N ( 2 ) . N ( l ) 

W p I T E < M , 9 6 0 1 N ( ? 9 ) , N R W , N ( 2 ) * ( ( R P T ( I , J ) . J s 1 , 10)  , N P T { 1 ) , 1 = 1 , N R W ) 

W R I T E < m , ? 6 0 ) N ( 3 n ) , m R W , N ( 2 ) , ( < T P T ( I ,J)  , J a 1 , 10)  , N P T ( ! ) . 1 = 1 , N R W ) 

WRTTr(Mf930)N(31),NRW,N(2),(TDMlN(I),|*l~NRW) 

ARlTr(M.9aO)Nj(3  2).NFIX.N(M),NFIX,N{M),((SEPTT(I,j4,J*l7NF!X), 

1 I « 1.  , N F I X ) 

’V  R I T F ( m , 9 q 0 ) N ( 3 3 ) , N ( 3 8 ) , N ( 1 ) i N ( 2 9 ) , N ( 5 ) 

WRtTE(m,910)NJ(39).TREG 

WR  I TE  ( M ,.9q0  ) N ( 9 0 ) , N ( 95  ) , N ( T ) » NRW  , N ( 2 ) 

VV  R I T E ( M f 9 1 0 ) N ( 9 6 ) .TEND 

WRTTE(M,9q0)M(«47)#Nf2).N(l)|N(29),N(5)#C(LAHBn(I.J)’.J*1.2<n.Ial.2l 
W R ! T F ( M , 9 0 0 ) N ( q 8 ) , I H 0 U R 

WRlTE(M,9q0)N(*49),NFlX,N(q),NF!X,N(9),{(SEP2(!,J),J=l,NFIX), 

1 I = 1 , N F I X ) 

WRITE  ( M , 9 5 n ) M(B0),N(^0),N(1).N(2),N(1) 

W R I T E ( M , 9 7 0 ) 

W R I T F ( M , 9 8 0 ) N ( 1 ) , I R F G , l.  , L 


900 
9 1 0 
920 
930 
990 
950 
960 
970 
980 

505 


F N D F I L F M 

FORMAT ( I q , 5 X | * 0 

FORMAT ( I q f 5 X , * 0 
FOrMaT(1*j,5)(,»1 

forma t f i q , 5x , • i 

FORMAT  ( I 9 , 5 X , * 2 

FORMAT ( 2 1 9 I I 2 . • 

FORMAT ( I 9 , 5 X , * 2 
FORMAT  f • • ) 

F0RMaT{|3".  19,  13.12) 

WRITE! 6 ,505) 

FORMAT ( //35X • a TRCRAFT  0F5cRIpTI0N*//16X*TYPE,21X*rPEED5  ( K N 0 T «:  ) »6X 
l • R 1 1 N w A y OCCUPANCY  (SECONDS)*  / 3 9X»LANDI  M G •9X'LIFT0FF*6X*LANDlN  r,  »6X 
2 • TAKFOFF  • //  ) 


R V?  I 3 9 ) 

R*,37XF7.3» 

R • , I 6 , l 9 , 2 7 X » • l 0 ( I 2 ) * / ( l n I 2 ) ) 

!6.I9,27X»,10(D3.9)*/(10F8.9)) 

I6.3I9,5X»  *R  F*,11X'»12(D1.9)#/(12F6.9)) 
. 15.319) 

16,  J9#  lRX»  • R * ,8X  , * 1 0 ( 12)  •/(  10I7.50XJ2)  ) 


P»  . 

7 • 
R*  . 


DO  1 A 0 I s ) , NT  yPF 
P R 0 T L s R 0 T L ( 1 ) * 3 6 0 0 . 

RROTT  = ROTT  ! I ) f 3600.  ,, 

wPITE<6,510)  I ,Vt,AND(  I ) ,VTOrF(  J ) .RROTL.RROTT 

510  FORMAT ( *0*  16*12, 21xF9.Q,7Xf9»0, 10XF9.0.9XF9.0) 

160  CONTINUE 

WP I TF ! A ,5  1 1 ) 

51 1 F0RMaT(//35X*TRAFFIC  DE5CRIPTiON*//31X*TYPE*5X*LAMDING*HX*TAKfOFF» 
1/92X»Mtx*8X*mix*//) 

A a P T Y P F.  ( 2 , 1 ) * 1 00, 
r=PTYPf(1,1)*100. 

WRITE  U,5l5)N<  1 ) ,A,B 
515  FORMAT (32x12, 2(7XF9,01/)  -169- 


1 65 
520 
5 2 1 
525 


I 70 
5 3 0 

1 75 
535 

1 50 
550 


1 85 
585 

1 90 


550 


1 95 


2 On 
555 


205 

560 


2 1 0 
565 


DO  U5  !«2.NTYPF 

A«(PTYpE(2.I  )-PTYPE(?tI-l  ) ) • 1 00. 
p « ( P T Y p E ( i ,1  )-PTYPF(  1 ,1-1  ) ) • 1 00. 
V P T T F ( 6 , 5 J 5 ) I , A , P 

CONTINUE 


WR  I TE ( 6 , 5?0 ) 

FORMAT ( * 1 A I P P 0 P t configuration* ) 

IF  ( INPUT  (B)  • NE  • * * )ivR!TE(6»52l  ) INPUT  (5) 

F0RMAT(«  FOp  ♦ A 3 , • AIRPORT*) 

W R I T F ( A , 5 ? 5 ) M R W 

rOPMATf///'  NIJMRFR  OF  RUNWaYS  «*I2) 

00  190  |s|  , N 9 W 

J = 0 P F R (!) 

GO  TO  (170*175,  1*0,  185).  J 

V’  R I T E < A , 530)1,  IhEAD(I),ILR(J) 

format  ( *nRtlMlV4Y*  12,  ' (M2,A2»*)  - TAKEOFFS  ONLY*) 


GO  TO  190 

R I T E C a , 5 3 5 ) I ,IHFAD(  I ) ,!LR(  I ) 

FORMAT  ( 'OR U N 8*  AY*  12,  • ( • I ? , A 2 * * ) - LANDINGS  ONLY*) 

GO  TO  190 

WRITE(6,5m0)I,IHEA0(I),!LR(I) 

F0RMAT(*nRUM'A/Ay*l2,*  ( • I 2 , A 2 % ♦ ) - DUAL  USE.  ALTERNATING  OPERATIONS 

1 • ) 

G 0 T 0 1 9 0 

W'RTTE(6,585)I~IHEAD(I),ILR(I) 

FORMaT(»0RUN’A'AY*I2,*  ( * ! 2 * A 2 » * ) - D U A |_  USE.  LANDINGS  TAKE  PRErEDEN 

IFF*) 

CONTINUE 
DO  195  I x ] , N R W 
DO  19  5 J s T , N R W 

I F ( D I N T ( I , J ) » I.  F • 0 , )G0  TO  195 
A*D  I NT ( J , j ) *6076 • 

R = 0 I N T r J , I ) * A 0 7 6 • 

^R!TE(6,550)IhEAD(I),ILR(I),IhEAD(J),ILR(J),A,IHEAD(I)#ILR(I)Ib. 

1 I HF AD  C J ) # I LR I J ) 

FORMAT f / / • 0 R U N AYS*  13,  A 2 , • ANo*I3.A2.*, INTERSECT  AT  A P0INT*F7.0, 

1*  F E F T FROM  T h E • / • FND  OF  pUnWA Y • I 3 , A?'  i AND*F7.0.*  FFET  FROm  THE 

2 F N D 0 F R U N A a y * I 3 , A ? , * . • ) 

continue 


I I = N R W - 1 

00  2 15  I « 1 , T T 

J J * I ♦ 1 

CO  21.8  JajJtNR'A» 

IF(INTFR(l,J),FO.n.AND.IHEAD(I).NE.IHFAD(J))GO  TO  2 1 5 
L * I N T F p ( r ,J)  + 1 

IF(IhEaD(I).NE.IHFAD(J))GO  T 0 211 
GO  T0( 200.205,210) , L 

WRiTfU.555)  IMFAD(  I ) ,ILR(  I i , I HEAD  ( J ) *ILR(J) 

FORMAT  < / • DRIJNVJA  y8  • I 3 , A 2 , * AND*I3,A2,*  ARE  INDEPENDENT  PARALLELS  -♦ 

1/'  S IMijLTaNfOUS  operations  ARE  PERMITTFD*) 

GO  TO  215 

W R I T E 1 6 , 5 6 0 ) IHEAD(  I ) . I L R ( I ) , I H E A 0 ( J ) *ILR(J) 

F0RMAT(/»nRUNWAYS*l3,A2,*  AND*  J 3,  A 2,*  ARE  SEMI-DEPENDENT  PaRAiLELS 
1 -*/•  SIMULTANEOUS  arrivals  arf  prohibited*) 

GO  TO  215 

WRlTrU,568)lHEAD(T),ILR(!),lHEAQ(J),]LR(J) 

FORMA  T ( /*oR UnwayS*  I 3 , A 2 . * AND*13,A2.*  ARE  DEPENDENT  PARALLELS  - • / 

1*  NO  S j MULT  ANfOijS  OPERATIONS  ARE  PERMITTED*) 

GO  TO  215 
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II  GO  Tn(?15.2l2,?l3),L 
212  WRlTFU,570)  I HFAD ( I ) , I L R ( I ) , I HE  AD ( J ) . I LR ( J ) 

570  FORHaT(/»oRuNwAYS*I3.,a?,*  A N D * i 3 , A 2 , * ARE  SEMI-DEPENDENT 
1 L T A N E 0 1 1 5 ARRIVALS  APE  PROHIBITED*) 

GO  TO  215 

? \ \ WPlTF(A*575)  I H E A D ( f ' lLR(t),lHEAO<J),ILRfJ) 

575  F 0 R M A T ( / • n R U N W A Y 5 * 1 A % A 7 . • A N D * I 3 , A 2 , * APE  D E P E M D E w T - * / * 
1ANF0US  OPERATIONS  PFRMITTFD*) 

215  CONTINUE 
STOP 

300  «V R I T F ( <5  .8*0  ) 

8A0  FOPMaT(*  WARNING  - 0 A 7 A T A PF  OOFS  NOT  CONTAIN  INFORMATION 

IE  requested  AIRPORT*) 

'•STOP 

•END. 


- • / • S I Mi) 


NO  S i M U L T 


A ROM T Th 
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APPENDIX  D 

LISTING  OF  THE  SIMULATION  PROGRAM 
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N 

GEN  R 

N 

R Al  A Y 

3 1 

2 I 

I 0 

E 

N 

N X T 0 P M 

N 

OP 

32 

2 I 

2 R IV 

E 

M 

land  r 

3T  YP 

E 

N 

TOFF  R 

RF  I X 

E 

N 

PT 

R 

I 

5 H 

r 

N 

FTIUPR 

T 

type 

1 

I 

A 0 P E P 

1 

I 

N 

PR  I NJ  T R 

N 

DL  A Y 

R 

F 

7DOM 

1 

F 

T 

Ft.  T q 

T 

T I N 

3 

F 

fl  N p T 

1 

I 

T 

T I F U P R 

9 FI.  YOM 

2 

F 

Nt 

ends  2 

T 

TH  I m 

1 

F 

1 odme 

1 

I 

M 

C H O u R 2 

T 

tmax 

2 

F 

1 1 VL  AND 

t 

E 

T 

DFt  X 

2 

I 

1 2 V T 0 F F 

1 

F 

\ 3 R 0 T L 

1 

F 

1 rrott 

1 

F 

T 

so 

R 

T 

1 SVT  A X T 

0 

E 

UDAFIX  G F 

1 7 S F P L L 0 F 

ISSEPTL  0 F 

19CALIN  1 F 

20CTYPE  2 F 

71CPWYT  2 F 

2 2 C R 1W  Y L 2 F 

2 3 C D F I X 2 F 


T POMTI  3 
T S 0 m T i q 
T P T M T i 3 
T S T H T I *4 
T PFPTI  3 
T SERTj  q 


2 R N E X T 1 I 

2 51  AST  l I 

260!MT  2 F 

27F0  2 I 

2PLQ  2 I 

29RPT  2 ! 

30TPT  2 I 

3 1 T n M I nj  i r 

325FPTT  2 F 

33NA&R  l I 

3 4 N 0 E p 1 I 

3 5 N L A N D 1 I 

3 6 N T D F F 1 I 

370ELT  | F 

3 A 0 E L L t F 

3 9 T B F G 0 F 

I ROFQMTI  l I 

! ‘ULOMTI  \ ! 

I R 2 F T H T I 1 I 

I R 3 L T w T I \ ! 

I R q F F R T I 1 I 

I rslfrti  1 I 

R6TEND  D F 

M7LAMBD  2 F 

RBIHOUR  0 I 

H9SFP2  2 F 

5 H G E 1 I 


0 2 F 


0 M T II  RTMA  X 
THT I I RTHA  X 
ERTIl  RTMAX 
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PT YPE I 
P R W A Y I 
PDF  I X I 
freerf 


L 

U 

L 


E V E m T S 
2 EXOGENOUS 
BEGIN  (i) 
EXGEN  (?) 

a endogenous 
' gen 
NXTOP 
LAND 
TOPE 
ETIUP 
CHOUR 
PRINT 
ENDS 

end  event  list 


EXOGENOUS  event  REGIN 
do  to  i . eor  each  o I 
create  gen 

STORE  GEn  in  GENN(I) 
store  I IN  OP(GEN) 

let  t»time.lamrd(  i ,ihOijo)*alog(  i • - r a n d m > 

CAUSE  GEn  at  T 
1 LOOP 

create  Ends 

CAUSE  ENDS  AT  TEND 

CREATE  chour 

CAUSE  CHOUR  at  TIME*!. 

RETURN 
end  begin 
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ENDOGENOUS  EVENt  gfn 

C GEN  GENERATES  landings  and  takeoffs  and 

C A s S T G N s ATTRIBUTES  TO  T H E M . 

C 0 p ( G E N ) IS  I-  T A K E o F E , 0 P 2-LA N DING 

S T 0 f?  r 0 P { G F N ) IN  I 

C GEN  SCHEDULES  ITSELF  TO  OCcUR  AGAIN  AFTER  A TIm£  INTERVAL 

C DEPENDING  DM  Thf  RATE  Or  OPERATION, 

CA'JsF  GFn  AT  TIMF-LAMRD(IiIHOUR)*ALO<3M.-RANDM) 

CREATE  flt 
let  I TsPTYPE ( I ) 

5 T 0 1?  E IT  in  TYPE  { E L T ) 

LET  K * P R V] A Y ( 1 . I T ) 

GO  TO  ( 1 , 2 ) , I 

C TIN(FLT)  IS  The  time  a flight  is  AVAILABLE  to  RfGIN  final 

C DESCENT  f F 0 R LANDINGS)  nR  TO  BEGIN  TAXIING  TO  RUNWAylFOR  TaKEOEE) 

C C A L T M IS  A TIME  LAG  INTRODUCED  IN  TAKEOFFS,  CORRESPONDING  TO 

C ELYnM  - THT  TIME  A LANDING  TAKES  TO  ELY  FROM 

C HA N DOTE  TQ  THE  0 U T F R MARKER, 

1 LET  T!N(FLT)*TIME+CALIN(K) 

LET  DF I X ( elT ) =PqE I X ( * ) 

IE  TIME  GE  TREG,  LET  NOEP < I HOUR ) «NOEP ( I HOUR  ) ♦ 1 
GO  TO  3 

2 let  TIN(FLT)sTTME+FLYOM(IT,K) 

IE  TIME  GE  TpEG.  L F T NaRR(!HOUR)»NARR(IHOUR)+1 

3 IF  O(K.I)  IS  NOT  FMPTY,  Go  TO  H 
CRE  A TF  NX  Tpp 

L F T P w A Y { N x T 0 P ) = K 
CAUSE  N X T 0 P AT  T T N ( F L T ) 

C O(K.I)  - IS  THE  QUEUE  OF  PLANES  WATTING  TO  T A K F OFF < I ■ i ) , 

C OR  LAND!  I a?)  ON  RUNWAY  K, 

*♦  FILE  el  T IN  0 { K . I ) 

RETURN 
E N P GEN 


EXOGENOUS  F v F N T F X G E N 

C EXGEN  GENERATES  EXPLICIT  DfPARTURES'aND  ARRIVALS 

save  event  card 
create _ flt 

read  !>,IT,DF!XCFLT) 

FORMAT  ( *4  I 2 ) 

STORE  T T IN  TYPE(FLT) 

GO  TO  (1,2),! 

1 LET  TIN(FLT)»TIME+CALIN(K) 

IF  TIME  GE  TRF.G,  Let  NdEP<IH0UR)«NdeP(IH0UR)4-1 
GO  TO  3 

2 LET  T I N ( El  T ) »T I MF  + FL YOM ( I T , K ) 

IF  T I M F GE  TREG,  LET  NARR<IHOUR)«NARR(IHOUR)*l 

3 IE  Q ( K ♦ I ) IS  NOT  EMPTY,  GO  TO  H 
CREATE  nxtop 

LET  RU'AY(NxTOP)*K 
CAUSE  NXTOP  AT  TIN(FLT) 

H E I LE  FLT  I N 0 ( K , I ) 

return 

end 
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r>  n 


FUNCTION  PTYPE(I) 

C P-TYpe  CHOOSES  an  AIRCRAFT  type  for  each  flight  according  to 

C CTYPF  - THE  CUMULATIVE  DISTRIBUTION  OF  A/C  TYPFS  IN  THE  MIX, 

let  R S r a n d M 

DO  TO  1 * FOR  EACH  TYP  J 
IF  R LE  CTYPF  < I , J ) , GO  TO  2 

1 LOOP 

2 LET  PTYPFsJ 
Return 

END  P T Y R E 


FUNCTION  PRWAY( I ,M) 

C PR  WAY  CHOOSES  A RUNWAY  FOR  EACH  FLIGHT  ACCORDING  TO 

C CRWyL  - THE  CUMULATIVE  DISTRIBUTION  OF  P RA  Y l ( SEE  P R E P R OC E S S 0 R ) 7 0 a 

C C RWyT  - SAME  AS  CR'VYL  FOR  TAKEOFFS, 

LFT  RsRANDM 

DO  TO  3, FOR  EACH  RW  J 
GO  TO  ( 1 ‘ 7 ) , I 

J IF  R LE  C R W Y T ( M , J j , 60  TO  <4 

GO  TO  3 

2 IF  R L.F  CRWYL(M.J),  GO  TO  H 

3 LOOP 

H LFT  PRAAYsj 

RETURN 
END  prway 


FUNCTION  prfTX(K) 

PDFIX  CHOOSES  A DEPARTURE  FIX  FOR  EACH  TAKEOFF  ACCORDING  TO 
C D F I X - THE  CUMULATIVE  DISTRIBUTION  OF  PDFIX  (SEE  PREPROCESSOR) 
LFT  RsRANOM 

no  to  i * for  each  fix  j 

IF  R L.  F CDFTX(K.J),  GO  TO  2 

1 LOOP 

2 LET  PDElXsJ 
Re  Turn 

end  pof i x 
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ENDOGENOUS  r V F N T N X T 0 P 

M X T n P DECIDES  '*>  HTH  0 p F r A T \ o N WILL  P F S C H E D U L F r>  NEXT 
0 N P4fM  PUM"MY. 

S T 0 R r R W A Y { N X T 0 P ' T 1 1 Y 
n p 5 t p o y NYTno 

ir  NEXT  NT  n , THE  next  OPERATION  Has  a l READY  been  decided  upon. 
IE  NFXT(K)  NE  o , WE  turn 
STOpe  o p e R ( < ) i m I 

ie  i of  3 , go  to  l 

TE  RUNWAY  HANDLES  ONIY  n N E OPERATION.  FIND  NEXT  FLIGHT 

waiting  in  the  queue  and  Schedule  it. 

find  E I R S T . FOR  E A c W F L T I N 0 { K , I ) , I F NONE,  RETURN 

STOrf  rLT  IN  E 

LET  T=FREFR ( K , I , F ) 

GO  TO  <4 

IE  RUNWAY  H A M D l_  F S pOTH  OPERATIONS  IN  ALTERNATION.  LOOK  FOR 
Next  EiIGHT  A!  TUG  tO  peR  FORM  THE  ALTERNATE  OPERATION, 

1 LIT  j = | A S T ( K ) 

IE  IANDIMGS  TAKE  PRECEDENCE,  ALWAYS  CONSIDER  THE 
LAST  OPERATION  TO  have  BEEN  A TAKEOFF. 

IE  T F Q M , LET  J s 1 
L e T T = - 1 . 

L F T I F I A G = O 
L F T T * i 

IE  J F Q 1 . L E T 1=2 
LET  TTs99?999» 

e I u D first,  FOR  fach  elt  In  q ( k , i > , i f none,  go  to  2 

STORE  ELT  IN  E 
let  I E (_ 4 G s | 

LET  T=EREER(K,I.E) 

I e T I N ( E ) is  T , SO  TO  M 
l.  E T TTsT 
LET  M=l 

2 LET  !=j 

ie  m o flight  available  n o a , search  the  other  Queue, 
find  FIRST,  for  each  elt  In  Q ( k , I ) , i e none,  go  TO  3 
STORE  flt  in  e 
LET  I E L A G S 1 
L E T T = erEERIK,I,E) 

IE  T I N ( E } L 5 T,  GO  TO  q 

3 ie  iflag  eq  n,  return 

IE  NO  FLIGHT  THFRE  EITHFR,  CHOOSE  THE  flight  which 
WIU.  PE  AVAILABLE  EARLIEST. 

IE  T L T tt.  go  TO  q 

LET  T = T T 
LET  I = H 

R LET  M E x T { K ) = I 

GO  TO  ( 5 , * ) , I 
5 C ° E A T E TOEE 

store  K in  R'VAY(TOFF) 

CAUSE  TOFE  AT  T 
R E T ij  R w 

a create  land 

STORF  K IN  R'"AY  (LAND) 

CAUSE  LaND  AT  T 
R E T ij  R M 
E Nj  D M X T 0 P 
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FUNCTION  FREER(K.I.FLT) 

freer  CALCULATES  THF  FIqST  time  AT  which  flight  FLT  can  PEpFORm 

OPERATION  I ON  PUNWAY  K WITHOUT  VIOLATING  SEPARATION  RULES. 
DIMENSION  T R ( 2 S ) 

let  J * o 

let  TaT  I me 

Ir  TIN(FLT)  S T T . LET  T a T I N ( F L T ) 

L F T M * T Y p e ( FLT ) 

LFT  erefr=t 

IF  T FQ  2,  GO  TO  <4 

IF  E R T I ( K J I S EMPTY,  RETURN 

ERTi(K)  IS  the  set  OE  *TIEUPS»  FOR  THE  end  OF  THE  RUNWAY  K. 

: a Ttfup  is  a time  interval  during  which  no  takeoff  may  occupy 

: the  fnd  of  the  runway  due  to  interference  from  other  aircraft, 

let  TFMsTomINK) 

: T 0 M T N I 5 A TIME  LAG  INTRODUCED  INTO  THE  SCHEDULE  OF  A TA<fOFF 

C CORRESPONDING  TO  The  TImE  IT  TAKES  A LANDING  TO  FLY  FROM  ThE 

C OUTER  MARKER  TO  TOUCHDOWN*  JT  MAY  RE  LOOSELY  THOUGHT  OE  AS 

c taxiing  time. 

DO  TO  3 , E 0 R EACH  TIE UP  IN  ERTI(K) 

LET  TTsTMAX (TTEUP)-TEM 

C THE  end  OE  THE  TIEuP.  I,E»  THE  TIME  WHEN  THE  END  OF  THE  RijmwAY 

C BECnMFS  FRfE,  is  displ  aceo  backwards  to  give  the  time  When 

c the  takeoff  may  begin  taxi. 

IF  TT  L S T , GO  TO  1 
LET  J = J-M 
LFT  TR  ( J ) aT  T 

LOOP 

GO  TO  1 2 

a I F OMTI(K)  IR  EMPTY,  GO  TO  g 
c OMT I IS  The  SET  OE  TIEUPS  for  the  outfR  marker, 
do  ro  s»  F 0 ° FACH  ttfup  IN  OMtI(K) 
let  TTsTMAX  (TlEllP) 

IP  TT  lS  T , GO  TO  s 
LET  J = J + 1 
LET  TO| J)sTT 
S L 0 0 o 

n IE  THTI(K)  IS  EMPTyI  GO  TO  12 
LET  TFM*DOMfK)/VLAND(M) 

C T H T T IS  T HF  SET  OF  TIEUpS  FOR  THF  THRESHOLD  OF  ThE  RUNWaY. 

DO  TO  9 * FOR  EACH’  TIEUP  I N T H T I ( K ) 

c THRESHOLD  TIE OPS  ape  DISPLACED  BACKWARDS  to  GIVE  thf  time  that 

c THE  LANDING  mAY  PASS  the  OUTER  MARKER. 

let  tt  = tm a X ( t I EUP  ) -tem 
IE  TT  L$  T , GO  TO  9 
LET  j a J ♦ I 
L E T TR(J)=TT 
9 LOOP 

12  IP  J EQ  0,  RFTURN 

let  r REER  = TQ ( 1 ) 

I F J EQ  1 , RETURN 

c FREER  is  SET  EQUAL  To  ThF  end  of  thf  latest  TIfUP,  WHEN  THTRE  is 

C NO  LONGER  any  INTERFERENCE, 

DO  TH  21,  FOR  J J a < j l ) ( J ) 

IF  TR(jJ)  gT  freer!  let  FREER«TR(JJ) 

21  LOOP 

RETURN 
.END  freer 
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ENDOGENOUS  FVFNT  1.  ANn 

LaMiv  CRKATfS  AI.I  TMF  'TtFUp5»  WHICH 
P F S i ; l T FROM  AM  A I u r p a F T LADING* 

S T 0 P r R W A Y ( I A M D ) I i* 

IF  !.)  ( K % ? ) T j NOT  FI"P  r,n  T 0 9 

W P 1 T F 0 N TAPr  A , T I M F , K 

FoKmM  (♦  AT  T I ME  • , M 3 . ? * S?  , * L AMO  I MG  QIJEUF  FOP  R U M w A Y * , I 3 S 2 , 

1 MS  F M P T Y M 
STOP 

FTNn  thF  L ANOINT  TO  nr  ♦sCHFDULFn*  ANn  STQWF  ITS  ATTRIBUTES. 

R F * 0 V F FIRST  F L T FROM  Q ( K * 2 ) 

5 T 0 P F F L T IN  F L 
LFT  MsTYPFiFL ) 

I.  F T V s V L A N 0 ( M ! 

I . F.  T T =.  F P F F R U , ? , f I ) 

L F T TO=T+nnMfKl/V 

TTF  u P THRFSHOLr  TO  LANDING  AIRCRAFT  PROM  TOUCHDOWN  TIME  U^TIL 
A F T F R RUNWAY  OCCUPANCY  TImF  WAS  ELAPSFD* 

CR^aTF  TIFI'P 

I.  FT  TM  I N ( T I rijP  ) -TO 

l rT  T M A X ( T I FllP  ) :T  0 ♦ R 0 T L ( M ) 

FTLf  T I E U P IN  THTt (K) 

C R E A T F F T I ! I P 
S T 0 p F < IN  R W A v ( F T f m p ) 

STOPf  ? IN  P T ( F T T l J P > 

CAUSE  FTIUP  AT  tmaX(TIEhP) 

T I F ||P  End  OF  RmNY/AY  to  DEPARTING  AIRCRAFT  FROM  TOUCHDOWN  i-NTIl 
A F T y P R u N w A V 0 c C U P A N c v T I M F HAS  F L A P S E D . 

C p E a T F T I F 1 1 p 

LET  TMjN(TirUP)sTf) 

L F T T m A X f t j F U R ) = t n 4 R 0 T L ( M ) 

F I L f T I E U P IN  E R T I ( K ) 

CREaTF  FtHiP 

STOrf  K I RWA  v ( FT  I UP  ) 

S T 0 R r 3 IN  R T ( F T I U P ) 

CAUSE  F T I Up  AT  TMAXITIF UP) 

FT  No  TmF  FOLLOW  IMG  PLANE  I 14  THE  LANDING  QUEUE 
AND  STORE  ITS  ATTRIBUTES. 

FIND  FIRST,  FOR  FACH  FLT  IN  0 ( K » 2 ) * I F NONE,  GO  TO  11 
STOrt  fLT  in  e 
LF  T MMsTYPF ( E ) 

LET  SsVLANn(MM) 

CREATE  A T T E i • P i • H I C H W I I L MAINTAIN  PROPFR  RADAR  SEPARATION 
BET  F F N ARRIVING  AIRCRAFT* 

C R E A T E T I PUP 

IF  S G F v/  , GO  TO  ?_D 

IF  THF  LANDING  SPEED  OF  T H y PLANE  BEING  ’SCHEDULED*  IS  GREaTER 

than  that  or  thf  following  plane,  tie  up  the  outer  m a r k e r from 
the  time  the  first  plane  Passes  the  outer  markfr  until 

TwF  TIME  IT  TAKES  THF  SECOND  TO  FLY  THE  SEPARATION  OISTANCF 

has  ELAPSED. 

let  T M I N ( T I E LJ  P ) S T 

LFT  TMAXfT!EUP)=T+SEPLL/S 

F I L r T I E U P IN  0 M T I ( K ) 

create  ft i up 

STORE  K IN  RWAY(FTIUP) 
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store  i in  pT(rTiuP) 
cause:  fthjp  at  t^ax  ctifuP  ) 

CO  TO  11 

IF  TMF  la  MOT  mg  SPEED  OF  T Hf  FOLLOWING  plane  is  greater,  tie  up 
THE  THRESHOLD  FROM  TOUCmD°WN  OF  THE  FIRST  UN Til  THE  TIME  IT  TAKER 
the  SECOND  TO  F|  Y T HF  SEPARATION  DISTANCE  HaS  ELAPSED, 

70  LET  TMIN(TTEUP)  * TO 

let  t m a x { t i e u p ) = t n ♦ s e p L i / s 

E I L E T I E u p IN  T H T I ( K ) 

CREATE  E t I UP 

STOpE  K IN  R W A Y ( F T I IJ  P ) 

STORE  ? IN  PT(ETIUP) 

CAUSE  eTIUP  AT  TT^AX  fTIEuP) 

11  IE  OPEP(K)  LT  3 , GO  TO  2 

CREATE  A T ! F 1 1 P WHICH  WILL  MAINTAIN  PROPER  SFPAPATION  BETWEFN 

t h i s landing  and  a takeoff  on  the  same  runway, 

CREATE  TIFi.ip 

LET  TM a X ( T I EUP  > =TD 

IE  D M E ( M ) g T 0 , GO  TO  1 

IF  the  LANDING  HAS  MO  DT STaNcE  MEASURING  EQUIPMENT,  TIE  UP  THE 
END  OF  RUNWAY  TO  DEPARTURES  FROM  THF  TIME  THE  LANDING  PASSES  ThE 
D/A  Fix  UNTIL  TOUCHDOWN. 

LET  TMlN(TTFUP)sT+rnOM(K)-DAFIX)/V 
GO  TO  1 0 1 

IF  THF  L A N n I M G HAS  ONE,  FIND  THE  T A < E 0 E E SPFFD  OF  THE 

DEPARTURE  AND  COMPUTE  TWE  TIE UP  NECESSARY  TO  MAINTAIN  SEPARATION. 

1 F I n D FIRST,  FOP  EACH  FLT  IN  Q ( K , 1 ) , IF  NONE,  GO  TO  2 
STORE  FLT  IN  F 

LET  M n = T Y P F ( E ) 

LrTS=VTOFF(MM) 

LET  TmiN(TTfUP)=T+(dOM(K)-(SEPTL^,S*V##2/S*P0TT(mM) ) ) / V 
mi  E I L r T I E u P IN  E R T I ( K ) 

CREATE  ETIUP 

STORF  K IN  RWAY(FTIL)P) 

STORE  3 IN  PT(FTIUP) 

CAUSE  F T I U P AT  TMAX(TIFUP) 

2 I F N P T ( K ) E R 0 , GO  TO  10 

NOW  CREATE  TIEUPS  ON  0 T H E r RUNWAYS,  IF  SUCH  INTERFERENCE  EXISTS. 
DO  TO  ft  » F o R Js(  1 ) (NPT(K)  ) 

CREATE  T I F u P 

KK  IS  THE  RIJN  Way  affected. 

LET  K K = R p T ( K . J ) 

IT  IS  THF  TYPE  OF  TIEUP  TO  re  CREATED. 

TlEijP  TYpfs  1,  2 * AND  6 APpLY  TO  LANDINGS. 

LET  I T = T P T ( K , J ) 

GO  TO  (3,ft,A,6,6.S) ,IT 

CREATE  a T]F UP  TO  MAINTAIN  INTER-ARRIVAL  SEPARATION. 

* El  No  FIRST*  FOR  EACH  FLT  I N Q ( K K , 2 > , IE  NONE,  GO  TO  6 
STORE  FLT  in  E 
LET  MMsTvpp ( r ) 

LET  SaVlANn(MM) 

IF  S GF  V,  GO  TO  325 
LET  TMlN(TlEUP)t=T 
LET  TMAX(TIE'JP)=T+SEPLL/S 
L E T J J * 1 
GO  TO  7 

3  2 S LET  THIN (TIE  U P ) ■ T D 

LET  TMa  X ( T I EUP ) sTu  + SEPLL/S 
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I FT  J Js2 
GO  TO  7 

CWFA.Tr  A T I r 'J  P TO  MAINTAIN  DFP/APR  SEPARATION. 

'+  LFT  THAX(TJCUP)*TD 

IT  n«EIM)  GT  0,  G 0 T 0 H 2 5 
L F T TM!N(TiFUP)=T4.(nO^(K)-nAFIX)/V 
GO  TO  q 5 rj 

Vr.  FlMn  FIRST  , FOP  FA  CM  FlT  IN  Q|KK,|  ) , IF  NONE  n 0 TO  6 
store  f L t in  f 

L F T Mm  = Typf(F) 

LFt  SaVTOFF(MM) 

lft  tmin(tje:uP)=t+(dom(k)-(Septl  + .5«v«*;?/s*rott(mM)  ) i / v 

G S n LFT  J J 3 3 
GO  TO  7 

TTF  IIP  The  end  or  an  INTFrSECTJNG  runway  TO  Ta<FOFFS  and 
until  a f t e R the  landing  p a s s f s t H F INTERSECTION, 

5 LFT  T M I N ( T I E u P l sTO 
L r T A*(VTAXI-V)/ROTL(M) 

LFT  TFM3.G*A*R0TI  (M)**2+v*R0TL(M) 

if  the  Landing  will  not  reach  thf  intersection, 

tie  UP  UNTIL  thf  L A N D ! M r,  TURNS  0 F F . 

IF  TEN  LE  D I N T ( K , K.  K ) , 6 0 T0  SI 

L r T Bsv**?*?,*A*niNT(K,KK) 

LFT  TUP=TD+  ( -V  + SQRT  ( R ) ) / A 
GO  TO  5 2 

SI  LFT  TUP*TD+ROTL(M) 

5 2 LrT  TmaX(TIFIJP)sTUP 

FILf  TlElJP  IN  ThTI(K'K) 

C P E A T F F T I II P 

STORE  KK  In  RWAY(FTIIJP) 

S T 0 R c 2 T N P T ( F T I U P ) 

CAUSE  FT  I UP  AT  TMAX(TIEuP) 

create  T I F l i d 
let  T M I N { T I E U P ) = T 0 
LFT  TMaX(TIFUP)*TUP 
L F T j j 3 .3 
GO  TO  7 

A DESTROY  TIFUP 
GO  TO  B 

7 GO  T0(70l  ,702,703), JJ 

701  FILE  TIFUP  IN  0 M T I ( K K ) 

GO  TO  70S 

702  FILE  TIE  UP  IN  THTI(KK) 

GO  TO  70S 

703  FILE  TlElJP  IN  ERTI(KK) 

70S  CREATE  FTJUP 

storf  kk  in  rway(ftiuP) 

STORF  j J in  PT(FTIUP) 

CAUSE  F T | UP  AT  THAX  (TIFuP) 

B LOOP 

10  CREATE  NvTO° 

STORF  K IN  R v A Y ( N X T 0 P ) 

LFT  N F X T { K ) sc  0 

CAUSE  nxtop  at  t 

; DTEm  is  thf  OElay  ENCOUmTEpeO  BY  this  LANDING, 

LET  DTFM«(t-TIN(FL))*AO, 

IF  TO  lS  T B F G , G 0 TO  SO 

create  print 


landings 
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c STOqe  data  TO  R F rfcordfd  AT  TOUCHDOWN. 

STORF  D T F M t M Dl  AY (PRINT) 

*5  T 0 p r < T Ki  R 'V  A Y ( p R I m t ) 

STORF  ? I n DP(PRINT) 

CAUSF  PRINT  AT  TO 
SO  DFSTROY  FIT  CALL  CD  FL 
LFT  LAST(<)=^ 
ofstroy  LA  no 

R F T (J  p N 
F N D LAND 
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ENDOGENOUS  EVENT  TOPE 

ToEF-  C&EATfS  THf  tie l- PS  RESULTING  From  an  AIRCPAFT  taking  off, 
STORE  RWAY(TOFF)  in  * 

destroy  toff 

If  o ( K , 1 ) I S EMPTY  , GO  to  16 

F?No  TaKEOfE  To  nr  SrHFDULpD  a no  STORE  its  ATTRIBUTES. 

REMOVE  FIRST  ELT  E^'nN  Q(K,1) 

S T 0 p r F L T IN  EL 
LET  ; i ■=  t Y p f ( r L ) 

L r T VsuTOff I M ) 

L E T T«fRF£R { K . 1 , FL ) 

LET  TnaTfTf)MlN(K  ) 

Tie  up  the  runwav  to  takfOffs  and  landings  for  duration  of  the 
P 1 1 N A v OCCUPANCY  time, 
create  T I FUP 

LET  T M I N ( T T F I J P I - T [ 

l.rT  T M A )(  ( T | F U P ) = ’ r,  + R r T T ( H ) 

F I Lf  TTFi.JP  IN  THTinn 

create  e t I I ) p 

STORE  K In  9 W A Y ( F T I II P ) 

STHpr  p I n PT(FTIUP) 
r a U S r F T I U p A T T M A Y ( T I E U P ) 

r^F ate  t i f u p 

L F T TMjN(TTEIJP)=TO 
I . F T T M a X ( T I E tJ  P ) s T 0 ♦ R 0 T T ( M ) 
r t Lr  T I FUP  I N e w T i ( K ) 

CREaTF  e t J i.  i P 

STOrf  K IN  p W A Y ( F T J u P ) 

STORF  T IN  P T f E T I U P ) 

C A 'J  S f F T I u p AT  T m A Y ( T I E U P ) 

r T Ml)  r j R 5 T , FOP  FAfH  ELT  Im  Q ( K , 1)  . IF  NONf.  G*  TO  ? 

S T 0 R E F !.  T JM  F 
L F T L = 0 E I y ( E ) 

L r T LLsOFIx(EL) 

tie  up  the  end  nr  tmf  runway  to  thf  nfxt  takeoff  long  enough 
TO  MAINTAIN  j n t f r - o f.  p a r t u r f separation,  this  depends  on  whether 
or  mot  thf  t o takfoees  dIvfrge, 
create  t I r I ) p 

LET  T M I N ( T I F U p ) = T D 
L E T TMaX(TifUP)sT()4SePTT(Ll,L) 

FTlr  T I E I J P IN  E R T I I K ) 

CRE  A TE  E T I IIP 

STORE  K IN  RWAy(ETIUP) 

STORE  3 IN  PT ( ET I U P ) 

CAUSE  E T I LJP  AT  TMAYfTIEUPl 
^ IE  OPER(K)  L T 3,  GO  TO  5 

find  first'  for  EACH  FLT  In  Q ( K , ? ) , if  NONE,  go  to  s 
store  flt  in  e 

LET  S=VLANn(TYPF(F) ) 

create  a t t r u p to  maintain  dep/arr  separation. 

CREaTP  T I Flip 

LET  T m i N ( T T F !J  P ) = T D 

I F n M F ( T Y p f ( f 1 ) F Q fl  . G 0 T n 3 

let  TMAX ( T T F I J P ) »TD+ (5EPTL+.S*S**2/V*ROTT (M ) I/S 
go  to  y 

3 LET  TM A X f T I EUP ) =TD  + D AE I X /5 

'4  E I L E T I F-  U P IN  T h T I ( K ) 
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CREATE1  FTIIJP 

STORE  < IM  R'-V  A Y ( F T I UP  ) 

5 T 0 p r 2 IN  ° T ( F T l U P ) 

CAU5F  F T ! U p aT  T^AX(TIFUP) 

IF  MPT(K)  F 0 G , GO  TO  IF 

CREATE  T ! F 1 1 P S 0 F OTHFR  RUNWAYS  AS  RFQUIRED. 

DO  TO  I S . FOP  J8  ( 1 ) ( MPT  ( < ) ) 

C p E A T F T I F u p 
K K - RUNWAY  AFFECTED 
L F T KKsRPT ( K , J ) 

IT  - TYPF  of  T I Flip 

ONLY  TYPFS  3 . M , S • AND  6 APPLY  TO  TAKEOFFS. 

LET  I T = T P T (K , J) 

GO  TO(l2f12,6.P,P.in),TT 

CREATE  A TIfUP  TO  MAINTAIN  PROPER  OEP/ARR  SEPARATION, 

A FT  NO  F I R S T , F 0 R FACH  FLT  I N Q ( K K , 2 ) ( TF  NONE,  GO  TO  1? 
STOqFFLTTNF 
L F T MMsIYPf  (F  I 

LFT  S = Vl.AND(NM) 

let  TM1N(TIEMP)*TD 
LPT  J J = 2 

IF  oME(TYPF(F))  E Q 0 , GO  To  7 

L p T TmaX(T!FHP)=Td+(FFPTL  + «B*S**?/V*ROTT(M)  )/S 
GO  TO  1 0 

7 LPT  TmaX  ( T I T U P ) s T D + DArlX/S 

go  to  n 

8 FIND  FIRST-,  FOR  F.ACH  FLT  I N 0(<K,  I ) , IF  NONE,  6n  TO  \ 2 
STOrf.  FLT  p'  p 

LFT  l s d p I X ( p 1 
LfT  LL=DFIX(PL) 

ORE  a Tr  A T I F I ' P TO  MAINTAIN  pROPFP  INTpR-DEPARTURE  SEPARATION. 

LET  TP  T N ( t T Ft'p  ) =TD 

if  tmf  Runways  a r f dependent,  use  the  same  separation  as  for  one 
riin^uyI  i.e.  those  in  The  septt  array. 

L p T TM A X ( T I E UP ) sTD  + SEPTT ( L , LL  ) 

IF  THF  RUNWAYS  allow  SIMULTANEOUS  DFpARTUReS  WmEN  THEY  dIVfRGE. 
USE  the  SEPARATIONS  IN  the  SEP2  ARRAY* 

IP  IT  F Q S .LET  TMAX(TIFUP)«TD*SEP2(L,LL> 

LET  J J = 3 
GO  TO  13 

TIE  UP  ThF  r N D Or  AN  INTERSECTING  RUNWAY  TO  A L I OPERATIONS  UNTIL 

the  takeoff  passes  the  intersection. 

LET  TMIN(TjeUP)sTD 
L F T A s V / R 0 T T ( M ) 

LEt  TFM=.S*A*ROTT(M)**?+V*ROTT(M) 

IE  THE  takfofe  is  airborne  reeore  rfaching  the  intersection, 

TIE  UP  ONLY  UNTIL  AIRBORNE, 

IF  TEN  LE  D I N T ( K , K K ) , GO  To  SI 
LFT  Rrv/**2*2.*A*DINT(K,KK) 

LFT  TUP=TD+ ( - V+SQPT { P ) ) / A 
GO  TO  S 2 

LET  ,TUP*TD+ROT T { M ) 

LET  TMaX(TIFUP)«TUP 
E T L f TlEtJP  IN  T H T I ( K K ) 

create  etiup 

STORE  <K  In  RWAY(ETIUP) 

STOrf  ? IN  PT(FTIUP) 

CAUSF  FTIUP  AT  TMAX(TIEUP) 
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C R E a T r T I E l ) p 

L-FT  TM  i N ( r T PUP  ) = T D 

t FT  TM  A X ( T I FUP  ) =TIJP 
LfT  JJ  = 3 
0 0 TO  13 

l 2 DESTROY  TIE'JP 
6 O TO  1 M 

13  0 0 T o ( i 4 , 1 ii  , 1 3 ? 1 . J J 

13  1 FILE  T j E U P IN  T H T ! ( K < ) 

00  TO  130 

13  2 FILE  TIF-Up  TM  ERTI(KK) 

135  CRFatF  FTIdP 

STOPE  K<  IM  RVAY(FTIUP) 
stOwf  j j I M p T ( F T I U P ) 

CAUSE  e T i t j P at  TmaMTIFiiP) 

1 q LOOP 

IS  CREATE  nxtop 

S T 0 p F < IM  R W A Y (NXTOP) 

LFT  m f_  x t i o = □ 

CAUSE  TOP  AT  T 

C DTFm  - THE  DELAY  INCURRED  By  THIS  T A K E 0 E F 

L r T DTEN*(T-TIN(FL))*60* 

IP  TO  ES  TBFO.OO  TO  50 

c p f a t e print 

c stOpe  data  to  be  recorded  at  thf  time  the  takeoff  turns 

c OF  TO  THE  RlJ  N Way. 

STORE  DTEM  in  DLAY(PRINT) 

STORE  K I M R W A Y ( D R I M T ) 

STUPE  1 IN  n p ( P R I M T ) 

C A U S F DRINT  AT  to 
SO  DFSTPOY  flt  CALlFD  FI. 

LET  l.  A S T ( < l s 1 
R r T ii  p m 

1 A WRITE  ON  T A P E A , TIME,  K 

format  <•  at  time*  ,d2*m,s2,  ’Takeoff  queue  for  runwa  y • , 1 .3  »s?  . 

| * T s E H P T Y • ) 

STOP 

END  toff 
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ENDOGENOUS  EVENT  F T I U P 

FT  I UP  REMOVES  TTFUPS  FROM  THFTR  SETS  AND  DESTROYS  THEM  WH[W 
SIMULATED  time  passes  the  END-LIMIT  of  the  t i e u p , 

STOrF  RWAY (FT  I UP)  IN  K 
STORp  PT(FTHJP)  IN  J 
DESTROY  FTIUp 
GO  TO ( 1 0 ,20 , 30  ) . J 
in  RFMOVE  FIRST  TIfUP  FROM  OMTI(K) 

GO  TO  4 0 

2 n r f m o w f first  tifup  from  t h t i t k ) 

GO  TO  40 

30  remove  first  tifup  from  e R t i ( k ) 

40  DESTROY  TIFUP 
RETURN 

end  f t I u p 


ENDOGENOUS  F V E N T PRINT 

PRINT  RECORDS  DATA  ON  EACh  FLIGHT  AT  THE  TIME  IT  ACTUALLY 
TOUCHES  DOWN  OR  TURNS  ON  To  THE  RUNWAY,  AS  THE  CASE  MAY  Be‘. 

S T 0 r F RWaY(PRINT)  IN  K 
STOrf  nL  A Y f PR  I NT ) IN  D 
STOrf  OP ( PR  I NT ) IN  I 
DESTROY  PRINT 

NTOFF  and  ml  AND  are  the  TOTAL  NUMBER  of  TAKFOFFS  AND  LANDINGS 
D U R f N G THIS  HOUp. 

DELT  and  dell  ACCUMULATE  Total  delay  on  TAKEOFFS  AND 
LANDINGS  BY  HOUR. 

GO  T 0 { 1 0 , 2 n ) , I 

10  L E T -,N  T 0 F F ( I H 0 U R ) * N T 0 E F ( I H 0 I J R ) ♦ 1 
L E T DELT!  I H 0 U R ) * D F L T ( I H 0 IJ  R ) + D 

return 

2 0 LET  ML.  A N D ( I H 0 U R ) = N L A n D ( I H 0 1 J R ) + 1 

LET  DELL!  IhOUR)«DELL(  I H 0 U r ) ♦ D 

RETURN 
END  PRINT 


endogenous  event  CHOUR 

CHOiiR  CHANGES  the  HOUR  a N D BEGINS  GENERATING  FLIGHTS  AT  THE 

rate  or  operation  for  TmF  new  hour, 

LET  I W 0 U R « I H 0 U R ♦ 1 

IF  I HOUR  gt  nh,  LfT  I HOUR®  I 

L E T TsT  I MF+  1 • 

IE  T L E TEMP,  CAUSE  CHOUR  AT  T 
DO  TO  h FOR  EACH  0 I 
STORE  GEnN ( II  IN  GEN 
CANCEL  GEN 

CAUSE  GEN  aT  T I MF-LAMPD  ( I . IHOIJR  ) *Al  OG  ( I .-RANDM  j 
1 LOOP 

RETURN 
END  CHOUR 
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ENDOGENOUS  fvfnt  f n d s 

IV R I T F ON  TAPE  A 

format  (u SUMMARY  RfPORT  For  THIS  RUN*///S3.,HnUR*,S10, 

] •OPrRATlONS  GENFPaTFO»,S10, ♦OPERATIONS  PERFORMED*  , S J 0 , 

7 ♦ T 0 T A L DFLAY  (MINUTFS)*,S8,*DELAY  PER  A / C (MINUTES)  * / S t S , 

3 ’LANDINGS  TaKEOFFG  TOTAL*, 55, •LANDINGS  TAKEOFFS  T 0 T A L • j 
mSG»*LANDINC,S  TAKEOFFS  aLl*,S7,»L  ANOINGS  TAKEOFFS  ALL’//) 

LFT  MARR«n 
LET  MDF.PaO 
irT  M l A N 0 * n 
LFT  MjOFFsn 
LFT  RheLTsO, 

LFT  R 0 F Ll.  = D , 

00  TO  ! , FOR  EACH  H I 
LET  N I N = N A R R ( I ) ♦ M P F P ( I ) 

L F T mjrRsma^R  + NaRR  ( I) 

LET  M0FP*MDFP+N0FP(I) 

LET  m 0 p = N L A N 0 ( I ) + N T 0 F F ( r ) 

LET  MLANDaMlAND+NLANOII) 

L E T MTOFFaMTOFF  + MTOFFl  I ) 

LET  TOFLanFLT  ( I ) ♦ D E L L ( I > 

LEt  ROFLT«roFLT^oELT ( I ) 

LFT  8DFLl=RDFLL+DELL(I) 

IF  NOP  E 3 0 , GO  TO  3 

LET  AOELsNOP 

LEt  AOFL»ToEL/AoFL 

IF  N L A N D ( I ) o T n * GO  TO  q 

LFT  A n F L L a n . 

GO  TO  R 

q LFT  A0FLl  = MLAND(  I ) 

LFT  AOFLLanFl.Ll  I )/ADFLL 
S IF  M T 0 F F ( M G T n,  GO  TO  A 

let  aoflt=o. 

G 0 TO  ? 

A LET  AOELTsNTOFF ( I ) 

LET  AOFLTsdELT(I)/ADELT 
GO  TO  7 

3 LET  AOFLsO. 

LET  A D F L L = fl  • 

LFtAofLT=0, 

2 WRITE  ON  Tape  6,  I , N A R R f I ) , N D E P ( I ) ,NTN,NLAnO(  I ) ,NT0FF(  I ) , NnP  , 
lDELL(T),nELT(I), TOE L.ADFLL.AOELT, ADEL 
format  (Sq,  I 2 • S t 2 • I?iS8^l2,SA,  13, S9,  I 2 , S 8 , I?,SA»  I3,S&»05* 1 .S3 
l DS . I , S 1 , D5 . 1 . SS  , DS  . 1 , S3  , D& • I , S 1 , DS , 1 ) 

1 LOOP 

LET  NTN*MARR+MDFP 
L E T NOPsMLAMn  + MTOFF 
LFT  TDFLsRDFLT^RDELL 
LET  AOFLaNOP 
LET  AOfLsTDEL / ADEL 

let  aoeLl=mland# 
let  ADELL«BDELL/ADELL 
L r T AOFLTsMTOFF 
let  AOFLTaRDELT/ADELT 

write  on  tape  a,  marR.mdfP  »nin,mland,mToff,nop*bdell  . b d e l t ,tdfi  , 
1A0ElL.ADELT.ADEL 

format  ( • 0.  T0TA(F*.Sl0.l3.S7il3,S5.fq.sa.I3*57,T3.S5,Il*,S5.n6«l, 

1 S 2 t D A . 1 » D A • 1 .SS.D5. 1 . S 3 , D 5 • I »S1  ,05.  1 ) 

S T 0 p 

’ END  END? 
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APPENDIX  E 

CONVERSION  TO  OTHER  COMPUTERS 

The  model  described  in  this  report  is  currently  operable  on 
the  National  Bureau  of  Standards  UNIVAC  1108  under  the  EXEC  II 
operating  system.  This  conputer  has  65,536  36 -bit  words  of  core 
storage  of  which  about  53,000  are  available  under  EXEC  II.  The 
model  consists  of  two  separate  programs,  the  preprocessor  and  the 
simulation , which  are  executed  in  succession  within  the  same  run 
under  EXEC  II.  The  preprocessor  output/simulation  input  tape  is 
rewound  between  the  execution  of  the  two  programs  by  a system 
utility  routine.  However,  the  REWIND  instruction  could  be  included 
in  the  preprocessor  program  if  desired.  For  both  programs  card 
input  is  from  logical  unit  5 and  printer  output  is  on  6.  The  airport 
data  file  tape  is  cn  unit  7 and  the  preprocessor  output/simulation 
input  tape  is  on  8.  The  airport  file  unit  may  be  altered  by  changing 
the  value  of  the  variable  IN  to  the  desired  unit  number.  The  pre- 
processor output/ simulation  input  unit  may  be  altered  by  changing  the 
value  of  the  variable  M in  the  preprocessor  program  and  putting  the 
corresponding  new  value  in  columns  35  and  36  (and  if  there  are  no 
explicitly  generated  flights,  in  columns  41  and  42  also)  on  the  system 
specification  card  required  as  input  to  the  simulation  program. 
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The  preprocessor  program  is  written  in  FORTRAN  V (the  UNIYAC 
augmented  FORTRAN  VI) . Several  features  which  have  been  used 
in  the  preprocessor  program  may  not  be  available  in  FORTRAN  IV 
compilers  on  other  machines. 

1.  The  PARAMETER  statement  is  used  to  define  the  value  of 
an  integer  constant  which  may  then  appear  as  a DIMENSION 
size  limit.  Such  variables  as  the  maximum  number  of  runways 
(KRW) , the  maximum  number  of  aircraft  types  (KTYP) , the 
maximum  number  of  departure  paths  (KFIX) , the  number  of 
operation  types  (KO) , and  the  maximum  number  of  interferences 
for  a runway  (KTPT)  are  all  defined  in  a PARAMETER  statement. 
The  compiler  treats  these  variables  as  constants , rather 
than  variables , but  their  values  may  be  altered  by  changing 
only  the  PARAMETER  statement,  rather  than  every  instance 

of  the  occurrence  of  the  value.  The-  use  of  the  PARAMETER 
may  be  circumvented  for  compilers  lacking  this  capability 
by  using  fixed  DIMENSION  limits  and  setting  KRW,  KTYP, 

KFIX,  KO,  and  KTPT  equal  to  the  appropriate  constants  at 
at  the  beginning  of  the  program. 

2.  The  UNIVAC  FORTRAN  V permits  an  end  of  file  condition  to  be 
detected  on  input  through  the  use  of  the  READ  (unit,  format, 
END  = i) , where  program  control  transfers  to  statement 
number  i when  an  end  of  file  is  read.  This  may  be 
circumvented  by  using  a particular  signal  sequence  of 
characters  and  testing  after  the  READ  statement. 
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3.  The  FORTRAN  V allows  the  use  of  quote  marks  enclosing  a 
Hollerith  field  in  a FORMAT  statement  and  also  in  an 
arithmetic  statement  such  as 

JAY  = ’J\ 

These  may  be  replaced  by  the  nH  form  if  the  compiler  does 
not  have  this  feature. 

4.  Mixed-mode  arithmetic  is  correctly  performed,  and  thus 
there  are  no  diagnostics  for  mixed-mode  expressions. 

Therefore,  although  care  has  been  taken  to  avoid  such 
expressions  some  may  have  survived. 

The  simulation  program  is  written  in  SIMSCRIPT  1.5.  The  user 
should  check  the  directions  for  compiling  SIMSCRIPT  on  his  particular 
machine.  On  the  UNIVAC  1108  SIMSCRIPT  1.5  compiles  into  SLEUTH, 
the  assembly  language, which  is  then  assembled  into  machine  code 
before  the  program  is  executed.  SIMSCRIPT  1.5  is  available  on  a 
variety  of  computers  and  is  quite  standard  from  one  machine  to  the 
next  since  most  of  the  compilers  were  constructed  by  the  same 
company.  Some  things  are  machine  dependent  and  should  be  checked 
when  using  other  computers. 

1.  Some  attributes  are  packed,  two  to  a computer  word.  The  packing 
allowed  may  depend  on  the  computer  word  size  for  other 
machines . 

2.  The  SIMSCRIPT  compiler  on  the  UNIVAC  1108  allows  both  LT 
and  LS  although  the  latter  is  standard. 
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3.  The  1108  version  of  the  compiler  accepts  Hollerith  strings 
enclosed  in  quotes  in  addition  to  the  standard  nH  form* 
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APPENDIX  F 


SEPARATION  BETWEEN  A LANDING  AND  A PRECEDING  TAKEOFF 

A landing  aircraft  which  possesses  DME  must  be  separated  by  a 
distance  S (currently  2 miles)  from  a preceding  takeoff  on  the  same 
runway.  In  this  appendix,  we  will  derive  an  expression  for  the  distance 
d which  must  separate  the  two  aircraft  when  the  takeoff  starts  its  roll, 
in  order  that  the  two  aircraft  remain  S apart.  We  make  two  assumptions: 

(1)  The  landing  speed  Vp  is  constant  along  to  the  final  approach  path. 

(2)  The  takeoff  acceleration  a is  constant  along  the  runway 
and  for  a short  while  after  liftoff. 

The  value  a of  the  constant  acceleration  can  be  calculated  from  the 
known  liftoff  speed  Vp  and  the  takeoff’s  runway  occupancy  time  R,  as 
a = Vp/R. 

Under  our  two  assumptions,  the  distance  Sp  the  takeoff  has  gone  in  t 
units  of  time  is 

s,  = (1/2)  a t2  = 0.5  vT  t2/R. 

The  distance  s^  traveled  by  the  landing  in  the  same  time  is 
s2  = VL 

Since  they  start  out  a distance  d apart  at  any  time  t they  are  separated 
by  a distance  D where 

D = 0.  5 Vp  tZ/R  - Vpt  + d. 

D must  be  always  greater  than  or  equal  to  S.  Differentiating,  we  find 
that  D is  minimum  when  t = R v]Vvp.  Since  this  is  the  time  that  the  two 
aircraft  will  be  closest,  we  set  D = S at  that  time  and  solve  for  d,  yielding 

Ve  assume  here  and  elsewhere  in  this  report  that  the  runway  threshold 
and  the  end  of  the  runway  are  gso graphically  the  same  point.  If  this  were 
not  true  an  appropriate  distance  would  have  to  be  added  or  subtracted  from  d. 
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2 

d = S + .5  R/vt. 

Therefore,  if  the  landing  is  this  distance  d from  the  end  of  the  runway 
as  the  takeoff  starts  its  roll,  the  two  aircraft  will  never  be  closer 
than  the  required  separation  S. 
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APPENDIX  G 


TIEUP  TIME  RESULTING  FROM  INTERSECTING  RUNWAYS 


In  order  to  compute  the  time  at  which  an  intersection  point  will 

become  free,  it  is  necessary  to  know  when  a landing  or  a takeoff  passes 

the  intersection.  In  this  appendix  we  will  derive  an  expression  for 

the  time  t it  takes  an  aircraft  to  travel  from  the  end  of  the  runway 

to  a point  a distance  D down  the  runway,  assuming  a constant  acceleration 

a along  the  runway.  The  value  of  this  acceleration  may  be  calculated 

from  the  initial  speed  v , the  final  speed  Vp  and  the  runway  occupancy 

time  R.  At  any  time  t the  speed  v of  the  aircraft  is 

v = a t + v . 

o 

However,  at  t = R the  speed  is  v^  so 
a = (v-l  - vq)/R. 

At  time  t<R,  the  distance  d traveled  by  the  aircraft  is 

d = 0.5  (v1  - v ) t^/R  + v t. 

K 1 oJ  o 

Setting  D = d and  solving  for  t yields 

t = -v  - /v  " + 2D  (v..  -v  )/R. 
o o v 1 o 


(V1  - vq)/R 

To  ascertain  which  sign  applies  here,  we  note  that  for  D > 0 we  must  have 
t > 0,  so  we  choose  the  positive  sign.  Therefore  since  t - R we  have 


t = min 


-v  + /v  2 +"  2D(v1  - vj  7k  ,R 
o o 1 o 

(V1  - V0)/R 
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To  interpret  this  for  a landing,  vq  is  the  (constant)  landing 
speed  and  is  the  speed  at  which  the  aircraft  turns  off  the  runway. 
This  yields  a negative  acceleration,  i.e.  a deceleration.  For 
takeoffs  v is  zero  since  the  aircraft  starts  off  at  rest,  and  is  the 
liftoff  speed  of  the  aircraft.  In  this  case  t simplifies  to 
t = min  |/2DR/v-p 
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APPENDIX  H 

(Mock)  Instructions  on  How  to  Use  the  KBS 
Airport  Capacity/Delay  Simulation  Model 
(Note:  The  Model  is  referred  to  here  as  ’’DELCAP”.) 

General  Information 

DELCAP  is  physically  located  within  a CDC  6600  computer  in  the  CDC  office 
building  located  at  11428  Rockville  Pike,  Rockville,  Maryland.  In  order  to 
access  it  you  use  the  time-share  terminal  located  in  Room  803  in  building 
FOB  10A.  The  instructions  for  turning  on  the  terminal  equipment  in  Room  803 
and  connecting  to  the  Rockville  CDC  6600  are  contained  in  a black  3-ring 
binder,  entitled  ’’Computer  Connection  Instructions,”  attached  by  a string  to 
the  wall  of  Room  803.  This  terminal  equipment  is  comprised  of  a card-reader, 
a printer  and  a Cathode  Ray  Tube  (CRT)  display.  This  equipment  and  DELCAP  are 
available  for  use  at  any  time  between  7 a.m.  and  8 p.m.  Monday  through  Saturday. 

What  DELCAP  is: 

DELCAP  is  a computer  model  which  can  be  made  to  represent  any  of  a broad 
range  of  actual  or  hypothesized  airport  configurations  (and  traffic  mixes) . 

Once  you  have  specified  the  airport  and  situation  for  analysis  - which  may  be 
done  in  either  of  two  ways , in  the  constructive  mode  or  in  the  on-file  mode  - 
you  may  then  ask  DELCAP  for  any  or  all  of  the  following  information: 

(a)  The  hourly  throughput  of  the  airport. 

(b)  The  average  delay  per  aircraft  using  the  airport. 

(c)  The  average  number  of  aircraft  waiting  to  take  off  or  land. 

These  quantities  are  gathered  separately  for  each  hour  and  over  a whole 
day,  and  may  also  be  broken  down  by  aircraft  type. 
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How  to  Provide  DELCAP  with  the  Information  it  Needs: 


This  may  be  done  by  using  DELCAP  in  either  its  constructive  mode  or  in  its 
on- file  mode.  Generally,  the  constructive  mode  is  to  be  used  when  analysis  is 
required  of  a proposed  new  airport  design  or  runway  changes  to  an  existing  air- 
port. Any  experimental  runway  configuration  may  be  analyzed  in  this  mode.  The 
on- file  mode,  by  contrast,  is  to  be  used  when  an  already -existing  airport  is 
to  be  analyzed.  The  runway  configurations  and  traffic  forecasts  for  these  air- 
ports will  be  permanently  stored  within  DELCAP.  For  example,  you  can  obtain  the 
capacity  and  delay  conditions  at  WNA  if  all  traffic  except  medium-size  jets 
were  prohibited,  or  the  throughput  and  delay  conditions  at  O’Hare  in  1985  when 
subjected  to  the  most  recent  traffic  forecasts  for  that  year. 

The  Constructive  Mode: 

To  use  DELCAP  in  this  mode  you  would  type  in  the  following : 

(1)  The  description  of  the  airport 

(1-1)  For  each  runway,  its  heading  and  the  distance  to  the  outer 

marker,  e.g.  runway  1,  heading  170  degrees,  distance  to  outer 
marker  8 miles. 

(1-2)  For  each  pair  of  intersecting  runways,  the  distance  from  the 
end  of  first  runway  to  the  intersection  with  the  second,  and 
the  distance  from  the  end  of  the  second  runway  to  the  inter- 
section with  the  first,  e.g.  3,  1,  5050.,  3020.  Runways  3 
and  1 intersect  at  a point  5050  feet  from  the  end  of  runway  3 
and  3020  feet  from  the  end  of  runway  1. 

(1-3)  For  each  pair  of  parallels  whether  or  not  they  have  independent 
approaches  and  whether  takeoff  on  one  are  independent  of  landings 
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(2)  The  description  of  the  traffic  using  the  airport. 

(2-1)  Aircraft  mix  by  type  of  aircraft  e.g.  9%  large  jets,  371 

medium  jets  and  large  propeller,  26%  medium  propeller  and  small 
jets,  181  light  twin  engine,  10%  single  engine. 

(2-2)  Number  of  arrivals  and  number  of  departures  per  hour  for  each 
hour  of  the  day 

(2-3)  Any  explicit  arrivals  or  departures  to  be  added  to  the  Poisson 
generated  flights  resulting  from  (2-2) . 

(2-4)  Distribution  of  use  of  departure  paths  for  each  runway. 

(3)  Description  of  certain  airport  parameters . 

(3-1)  Mix  of  runway  use  by  aircraft  type  for  landings  and  separately 
for  departures  e.g.  40%  of  large  jets  land  on  rumay  1 and 
60%  on  runway  2.  20%  of  large  jets  take  off  from  runway  1 and 

80%  from  runway  2. 

(3-2)  Minimum  spacing  rules 

a.  Interlanding  e.g.  3 miles  for  IFR  approaches 

b.  Landing  following  a takeoff  e.g.  2 miles 

c.  Between  takeoffs  - one  for  those  using  the  same  departure 
path,  and  another  for  those  using  different  departure  paths 

9 

for  the  same  runway  e.g.  1 minute  between  departures  using 
different  paths  and  3 miles  between  departures  using  the 
same  path.  With  noise  abatement  procedures  in  force  the 
1 minute  might  be  increased  to  2 minutes . 

(3-3)  Aircraft  type  characteristics. 

e.g.  final  approach  speed,  typical  runway  occupancy  time  for 
each  type  of  aircraft. 
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The  On- File  Mode: 


To  use  DEL  CAP  in  this  mode  you  must  type  in  the  following: 

(1)  Airport  designator  e.g.  (JFK) 

(2)  Any  changes  to  filed  items  (2)  or  (3)  of  the  Constructive 
Mode  Parameters. 
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